Development of Accessible E-documents and Programs for the Visually Impaired WAI-ARIA (V 2011)
1. WAI-ARIA • accessible rich internet applications • a W 3 C protocol for enhancing and supporting accessibility of scripted and dynamic content • defines a way to make web content and web applications more accessible to people with disabilities • helps especially with dynamic content and advanced UI controls developed with ajax, Java. Script. . .
2. WAI-ARIA (2) • certain functionality used in web sites is not available to some users with disabilities • especially to people who rely on a screen reader • and people who cannot use a mouse • ARIA addresses these accessibility challenges
3. Example of the problem 1
4. Example of the problem 1 • a list of items with one item expanded to show a sub-list • tree control is often used for site navigation • assistive technologies need to be able to interact with these controls • semantic information that the A. T. need is not available with most current web technologies
5. More examples of problems • drag and drop functionality: not available to users who use a keyboard only and cannot use a mouse • dynamic changes: the contents of a web page changes in response to user actions or time / event based updates
6. What ARIA provides to developers • roles to describe the type of widget presented, such as "menu, " "treeitem, " "slider, " and "progressmeter" • roles to describe the structure of a web page, such as headings, regions, and tables (grids) • properties to describe the state widgets are in, such as "checked" for a check box, or "haspopup" for a menu.
7. What ARIA provides to developers (2) • properties to define live regions of a page that are likely to get updates, as well as an interruption policy for those updates. For example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page. • properties for drag-and-drop that describe drag sources and drop targets • a way to provide keyboard navigation for the web objects and events, such as those mentioned above
8. Roles • a simple way for an author to make custom widgets (new interactive elements) accessible, usable and interoperable • using roles you can assign a role name to an object that maps this object to the accessibility framework on the native platform and provides semantics needed by adaptive technologies
9. Roles (2) • interaction widget • structural document objects • when possible, role information is mapped to a platform’s accessibility APIs • roles are element types and should not change in time or after user actions
10. Roles (3) • encoded in RDF (resource description framework) • encoded is: the inheritance information and details of what states and properties each role supports • roles are defined and described by properties
11. Roles (4) examples of properties: • Supported. State: which states are supported by the role • Must. Contain: a child element that must be contained e. g. a list must contain list items • Scope: context where the role is allowed (e. g. a list item can be only inside a list) • . . .
12. Widget roles • used to announce the type of custom UI component • are all mapped to accessibility APIs • examples: link (interactive reference to a resource), combobox, option (a selectable item in a list), checkboxtristate, button, menuitemradio, menuitemcheckbox, progressbar, slider, textarea, textfield, treeitem,
13. Widget roles (example) <html xmlns="http: //www. w 3. org/1999/xhtml" xmlns: wairole="http: //www. w 3. org/20 05/0/wai-rdf/GUIRole. Taxonomy#" xmlns: aaa="http: //www. w 3. org/2005/ 07/aaa" > <head>. . . </head> <body>
14. Widget roles (example) <span class="checkboxtristate" id="chbox 1" role="wairole: checkboxtristate" aaa: checked="mixed" onkeydown="return check. Box. Event(event); " onclick="return check. Box. Event(event); " tabindex="0" > A checkbox label </span> </html>
15. Widget roles (real examples on the web) • editable grid and application menu (both are fully accessible) • grid can be edited by pressing enter in a particular cell • application menu works as standard menu • url: https: //wwwarchive. mozilla. org/access/dhtml/spreadsh eet
16. Structural roles • describes the structure of a document • help assistive technologies determine active VS. static content • examples: application (notifies screen reader that it's time to switch to application mode and disable linear processing of this part), document (linear processing is ok), liveregion (can be automatically changed and so must be periodically tracked by screen reader), Grid, tabcontainer, tab, . . .
17. Landmarks • navigational roles • special roles to mark parts of a document • user can use these marks to quickly find particular part of the page • supported by modern screen readers • easy to incorporate into existing pages
18. Available landmarks • Application: a region declared as a web application as opposed to a web document • Banner: a region that contains the primary heading or web site title - mainly site-oriented: usually contains logo of the site, main heading of the site and a site search tool. . . - only one element can be marked by this role • Complementary: a supporting section of a document that remains meaningful even when separated from the main content - for example, it can be used on portals to show information like weather, TV program, . . .
19. Available landmarks (2) • Contentinfo: Metadata that apply to the parent document, for example, footnotes, copyrights, and links to privacy statements would belong here. • Main: The main content of a document can be used as an alternative to "skip to main content" link • Navigation: A collection of navigational elements (usually links) for navigating the document or related documents • Search: The search tool of a web document
20. Landmarks example <div id="maincontent" role="main"> <h 3>main content</h 3>. . . </div>
21. Simple practical ARIA example • a form with mandatory and optional fields • ARIA attribute is used to mark mandatory fields • automatic validation of some elements • alert ARIA widget is used to notify the user about wrong contents of a particular field • the contents of the alert widget are automatically reported by a screen reader
22. How it works • mandatory fields are announced as required by the screen reader • onhower event (triggered when focus leaves a particular control) starts validation function • if a particular control contains wrong data, the alert widget is created and added to the document • the alert widget automatically fires "alert event" which is caught by the screen reader and a user is informed about its content
23. Simple form <form method="post" action="post. php"> <fieldset><legend>Please enter your contact details</legend> <label for="name">Your name (required): </label> <input name="name" id="name" ariarequired="true" onblur="check. Validity('name', 'Invalid name entered!'); "/><br/>
24. Simple form (2) <label for="email">E-Mail address (required): </label> <input name="email" id="email" ariarequired="true" onblur="check. Validity('email', '@', 'Invalid e-mail address'); "/><br/> <label for="website">Website (optional): </label> <input name="website" id="website"/>
25. Simple form (3) </fieldset> <label for="message">Please enter your message (required): </label><br /> <textarea name="message" id="message" rows="5" cols="80" ariarequired="true"></textarea><br /> <input type="submit" name="submit" value="Send message"/> <input type="reset" name="reset" value="Reset form"/> </form>
26. check. Validity function description • three parameters • a trivial function which searches for the second parameter in the element in the first parameter • the third parameter contains the error message • see again: <input name="email" id="email" ariarequired="true" onblur="check. Validity('email', '@', 'Invalid e-mail address'); "/>
27. check. Validity function javascript code function check. Validity(a. ID, a. Search. Term, a. Msg) { var elem = document. get. Element. By. Id(a. ID); var invalid = (elem. value. index. Of(a. Search. Term) < 0); if (invalid) {
28. check. Validity function javascript code (2) elem. set. Attribute("aria-invalid", "true"); add. Alert(a. Msg); } else { elem. set. Attribute("aria-invalid", "false"); remove. Old. Alert(); } }
29. remove. Old. Alert function • a simple function which looks for an element with "alert" id and removes it if possible function remove. Old. Alert() { var old. Alert = document. get. Element. By. Id("alert"); if (old. Alert) document. body. remove. Child(old. Alert); }
30. add. Alert function description • another simple function • one parameter with text of an error message which we want to have in the alert widget • Notice the special attribute to set role.
31. add. Alert function javascript code function add. Alert(a. Msg) { remove. Old. Alert(); var new. Alert = document. create. Element("div"); new. Alert. set. Attribute("role", "alert"); new. Alert. set. Attribute("id", "alert"); var msg = document. create. Text. Node(a. Msg); new. Alert. append. Child(msg); document. body. append. Child(new. Alert); }
32. Live region example • The following example demonstrates how to implement logged-in users list. • Live region properties are used to inform the screen reader that the contents of a particular element (<ol> in our case) may change • Screen reader tracks the contents of properly marked elements and informs blind users about changes inside the region • This kind of list can be modified by e. g. a javascript function and will be perfectly accessible
33. Example of lr - html code <p id="users-desc">A list of the currentlyconnected users. </p> <ol aria-live="polite" aria-relevant="additions removals" aria-describedby="users-desc" id="users"> <li>John</li>
34. Example of lr - html code (2) <li>Mary</li> <li>Ted</li> <li>Jane</li> </ol>
35. Explanations of used aria options aria-live: • if defined then the screen reader knows that the element is live region • possible values and their meanings: - off: Updates to the region should not be presented to the user. - polite: Updates should be announced at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses their input typing. - assertive: This information has the highest priority and user agents SHOULD notify the user immediately
36. Explanations of used aria options (2) aria-relevant: • which types of changes in the region will be announced • possible values and their meanings: - space-delimited list of one or more values: - additions: nodes are added to the DOM within the region - removals: nodes are removed from the DOM - text: text is added or removed from the DOM - all: equivalent to the value "additions removals text"
37. Explanations of used aria options (3) aria-describedby: • identifies the element (or elements) that describes the object • value can be a white-space delimited list of ids with descriptions • similar to aria-labelledby
38. Resources • WAI-ARIA specification: http: //www. w 3. org/TR/wai-aria/ • WAI-ARIA best practices: http: //www. w 3. org/TR/wai-ariapractices/ • Marco Zehe's accessibility Blog (brilliant resource with examples and explanations): http: //www. marcozehe. de • John Resig's userlist example: http: //ejohn. org/blog/ajaxaccessibility/ • WAI-ARIA 1. 0 User Agent Implementation Guide: http: //www. w 3. org/WAI/PF/aria-implementation/ • Nice collection of aria examples: http: //test. cita. uiuc. edu/aria/
Скачать презентацию Development of Accessible E-documents and Programs for the
379746ac6f6b07b5794fb497874cf14b.ppt