An Introduction to WAI-ARIA
Download as PPT, PDF4 likes3,763 views
The document introduces WAI-ARIA, a W3C specification designed to enhance web accessibility for individuals with disabilities by defining roles, states, and properties for user interface elements. It discusses the challenges of HTML limitations and explains how ARIA can facilitate keyboard navigation, improve dynamic content updates, and assistive technology compatibility. It highlights best practices and resources for developers looking to implement ARIA for enhanced accessibility.
An Introduction to WAI-ARIA
- 1. An Introduction to WAI-ARIA Dan Jackson Web Team Leader City University London
- 2. About this session What is ARIA? What does it do? Why do we need it? Roles, States and Properties, keyboard navigation, Live Regions Where ARIA we with ARIA? * Problems & Issues Best practice * All my puns are rubbish.
- 3. Get the acronym out of the way early doors.... W eb A ccessibility I nitiative. A ccessible R ich I nternet A pplications. It’s at ‘Final Call’ draft stage, i.e. it’s not a formal specification (yet) .
- 4. What does ARIA do? W3Cese “ This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information in document-level markup, to an assistive technology .” ( http://www.w3.org/TR/wai-aria/ ) English It’s a W3C specification that defines a way to make Web content and Web applications more accessible to people with disabilities.
- 5. Why do we need ARIA? Some background... HTML is so, like, 1999 : very limited set of interface controls. difficult communication model JavaScript is bitchin’: dynamic interactions (drag & drop, sorting, resizing) widgets (date pickers, sliders, tabs, progress bars, etc) AJAX
- 6. Why do we need ARIA? So what’s the problem? Widgets are inaccessible - Assistive Technologies (AT) don’t know what they do. Widgets are rarely keyboard accessible. Content updated using AJAX is not reported to AT.
- 7. ARIA to the rescue! ARIA provides semantic meaning , dynamic content updates and consistent keyboard support to AT users.
- 8. Roles States and Properties Keyboard access Live Regions The technical part
- 9. Roles Roles define widgets and page structure. 2 categories: Landmark Roles Widget and Element Roles
- 10. Landmark Roles “ The skip-links killer” Define the role of sections in the structure of a web page, e.g.: <div id=”header” role=”banner”> <div id=”content” role=”main”> Gives AT instant access to major page components
- 11. Landmark roles
- 12. Widget & Element Roles To describe GUI widgets, elements common on desktop but not native to HTML. Examples: grid menu progressbar slider tab toolbar tree
- 13. States and Properties Provide AT with information about how elements & widgets are configured, e.g.: has a button been pressed? <button aria-pressed=”true”> is an input field required? <input aria-required=”true”> how much of my file upload is complete? <div role=”progressbar” aria-valuetext="0%" aria-valuenow="0" aria-valuemax="100" aria-valuemin="0">
- 14. Accessibility isn’t just about screen readers.... Throw away your mouse.
- 15. Keyboard access ARIA extends the use of HTML’s tabindex attribute. tabindex = “0” : allows all elements to be accessed using keyboard. tabindex=”-1” : allows elements to be given programmatic focus without adding them to the tab order.
- 16. Eh? This is a good thing . Why? Easier navigation through document, i.e. one ‘tab stop’ per UI control. Gives keyboard access to widgets. Manages keyboard control within widgets. Establishes relationships between elements within widgets (e.g. parent/child/sibling in tree-view navigation).
- 17. Live Regions Are Way Cool Solves the problem of how to announce content updated by AJAX to screen reader users. Properties : aria-live = off | polite | assertive | rude aria-atomic = true | false aria-busy = true | false aria-relevant = additions | removals | text | all
- 18. Problems, issues: The V-Word ARIA vs. HTML 5 Is it supported? Complexity Will AT users adopt it? Where aria we with ARIA?
- 19. Issue #1: The V-Word Any Validation Nazis in the room? ARIA won’t validate with HTML 4.01, XHTML 1.0. What to do? Put up with it. Inject attribute values using JavaScript. Create a custom DTD! Use HTML 5!?
- 20. Issue #2: ARIA vs. HTML 5 ARIA Landmark Roles <div role=”navigation”> ARIA Properties and States <input name=”email” aria-required=”true”> HTML 5 New structural elements <nav> HTML 5 form attributes <input name=”email” type=”email required”> But... Many ARIA roles that have no HTML5 equivalent, e.g. application, banner, main . And… Argument over structural elements in HTML 5 = major shit-storm.
- 21. Issue #3: Is ARIA supported? To use ARIA you need a browser that both supports ARIA and is supported by a screen reader that also support ARIA . ARIA-aware OS/browser/AT combinations are some way off becoming the norm. Browsers: Firefox 1.5+, Opera 9.5+, IE8, WebKit http://www.paciellogroup.com/blog/aria-tests/ARIA-SafariaOperaIEFF.html
- 22. Issue #3: Is ARIA supported? Screen readers ZoomText 9+ JAWS 7.1+ NVDA (free!) VoiceOver (free!) FireVox (free!) Orca JavaScript Libraries Jquery UI YUI Dojo ExtJS GWT Glow (BBC)
- 23. Issue #4: Complexity ... it’s not exactly plug’n’play! It’s a task just to set up the development environment. Key board navigation requires complex JavaScript coding.
- 24. Issue #5: Do AT users update? Screen reader? Mostly. Browser? Questionable. http://www.webaim.org/projects/screenreadersurvey/
- 25. ...it’s not all doom and gloom Support is growing. You can use ARIA to improve your website right now . (Landmark Roles, Live Regions)
- 26. Best practice WAI-ARIA is just one ‘layer’ of accessibility. Don’t withhold content from users without JavaScript (use HIJAX). Best practice techniques for front-end web development, & layer ARIA on where possible.
- 27. Resources http://dev.opera.com/articles/view/introduction-to-wai-aria/ Probably the best introductory article online . http://wiki.codetalks.org/ Excellent set of ARIA test cases. http://paciellogroup.com/blog Great all round accessibility resource, with emphasis on ARIA. http://www.w3.org/WAI/intro/aria Understandable W3C introduction to ARIA.
Editor's Notes
- #3: About me & the session Broad range of managers & team leaders, developers, content editor, ‘strategist’. Where to pitch this? It’s complex, still in development. Overview of session content. What does it mean, what does it do? Why do we need it? The nitty gritty: Roles The nitty gritty: States and Properties The nitty gritty: Keyboard navigation The nitty gritty: Live Regions Where are we with ARIA? Problems & Issues Best practice, take aways
- #4: WAI is the ‘branch’ of W3C that develops accessibility standards guidelines. In addition to WAI-ARIA, WAI are also responsible for WCAG (which I’m sure you’ve all at least heard of), plus some others that you might not have, e.g. ATAG (authoring tool) & UAAG (user agent).
- #5: Continuing with the WAI theme... If WCAG addresses the information in a Web site (text, images, forms, etc). ARIA addresses dynamic Web content and Web applications .
- #6: Some background... HTML isn’t ideal for the development of highly fluid, responsive interfaces and applications that give us a richer user experience: It has a very limited set of interface controls . Its communication model is sequential (client-server-client). We use JavaScript to overcome these limitations: Adds behaviour , & allows us to create dynamic interactions (drag & drop, sorting, resizing) widgets (date pickers, sliders, tabs, progress bars, accordions) & effects (animation, toggle, show/hide). AJAX allows us to query the server in a far more responsive fashion.
- #7: Widgets are inaccessible - assistive technologies (AT) like screen readers don’t know what they do or what state they are in. They are rarely keyboard accessible. Content updated using AJAX is not reported to AT.
- #8: It maps existing, well-known concepts from the operating system to the browser by: Adding semantic meaning to meaningless markup : “provides a means of describing... custom widgets so that they are recognisable and usable by assistive technology users.” ( http://dev.opera.com/articles/view/introduction-to-wai-aria/ ) Communicating dynamic content updates (AJAX) to assistive technology. Providing consistent keyboard support for interactive interface elements.
- #9: Roles States and Properties Keyboard access Live Regions
- #10: Roles define widgets and page structure. Broadly fall into 2 categories: Landmark Roles Widget and Element Roles
- #11: Landmark roles: the “ skip-links killer” Help screen reader users understand the role of sections in the structure of a web page, e.g.: <div id=”header” role=”banner”> (site-oriented content, e.g. logo, page title) <div id=”content” role=”main”> (central document content) <div id=”nav” role=”navigation”> (links to navigate this document &/or related documents) Allows AT’s instant access to major page components They can be used now. Example: landmark roles - image & web
- #13: Widget & Element Roles: To describe GUI widgets & elements common on desktop, but not native to HTML, e.g. grid, menu, progressbar, slider, tab, toolbar, tree, etc. Especially useful when widgets are built with existing HTML elements (images, buttons, lists) that may not convey real purpose to screen reader
- #14: States and Properties Provide AT with information about how elements & widgets are configured, to help users understand how to interact with them, e.g.: has a button been pressed? <button aria-pressed=”true”> is an input field required? <input aria-required=”true”> how much of my file upload is complete? <div role=”progressbar” aria-valuetext=&quot;0%&quot; aria-valuenow=&quot;0&quot; aria-valuemax=&quot;100&quot; aria-valuemin=&quot;0&quot;> EXAMPLES
- #15: Accessibility != just screen readers . Is your website usable without a mouse? Being able to interact with interface elements using keyboard alone is a basic accessibility provision.
- #16: Keyboard access How does ARIA enhance keyboard access? By extending the use of HTML’s tabindex attribute: tabindex = “0” : extends HTML’s tabindex attribute so all elements can be accessed using keyboard ( not just anchors, form elements ) . tabindex=”-1” : allows elements to be given programmatic focus without adding them to the tab order.
- #17: (This is quite technical.) Why is this “a good thing”? Allows easier navigation through document, i.e. one ‘tab stop’ per UI control (e.g. “I don’t want to have to tab through this long list of links”) Gives keyboard access to widgets. Manages keyboard control within widgets. Establishes relationships between elements within widgets (e.g. parent/child/sibling in tree-view navigation). Example: Google Reader using Google’s AsxJAX framework ( http://code.google.com/p/google-axsjax/ ) Greasemonkey script .
- #18: Live Regions It solves problem of how to announce content updated by AJAX to screen reader users. Does this by defining sections of document where content is updated dynamically. Properties: aria-live = off | polite | assertive | rude (how aggressive should screen reader be in announcing updates? Can be used with any existing HTML element.) aria-atomic = true | false (read entire live region on change, or only new content?) aria-busy = true | false (can set to true until final part of live region has loaded. Prevents AT announcing changes before updates complete.) aria-relevant = additions | removals | text | all (what changes are considered relevant?) Example: Twitter live update
- #19: The V Word ARIA vs HTML 5 Still in draft & being developed. Is it supported? Complexity (coding, testing) Do AT users update?
- #20: ARIA roles & attributes won’t validate with HTML 4.01 or XHTML 1.0. What are the choices? Put up with it. Add attribute values using JavaScript (easy using JavaScript libraries like JQuery). Create a custom DTD! Use HTML 5!? W3C’s validator ( http://validator.w3.org/ ) has experimental support for HTML5 with ARIA.
- #21: Conflict between proposed HTML 5 spec & ARIA, specifically: HTML 5 structural elements vs ARIA landmark roles: <div role=”banner”> or <header> or <header role=”banner”>? HTML 5 form attributes and states vs ARIA properties and states: <input name= ” email ” type=” email required” > or <input name=”email” aria-required=”true”> From official WAI-ARIA spec: “If the host language incorporates WAI-ARIA support and there is a conflict between a host language feature and an WAI-ARIA feature, assistive technology SHOULD assign preference to the WAI-ARIA feature.” BUT are number of ARIA roles that have no HTML5 equivalent, e.g. application, banner, main, search (see http://www.paciellogroup.com/blog/?p=106 ). Structural elements in HTML 5 argument = shit-storm. Worth reading up on this if you’re interested in the development of HTML5 - definitely check out zeldman.com; “HTML5 is a mess: now what?”.
- #22: ARIA-aware OS/browser/AT combinations are some way off becoming the norm. This is really important : To use ARIA you need a browser that both support ARIA and is supported by a screen reader that also support ARIA . Browsers . Firefox 1.5+, Opera 9.5+, IE8, WebKit are in various stages of implementing the specification. BUT: Webkit support in both Mac & Windows is poor. Support is patchy even in best browsers.
- #23: Screen readers . ZoomText 9+, JAWS 7.1+, NVDA, VoiceOver, FireVox, Orca. All differ, none are perfect. JavaScript libraries : Many popular libraries (JQuery UI, YUI, Dojo, ExtJS, GWT) )are in the process of adding support for ARIA. Great resource is http://www.paciellogroup.com/blog/?p=313 .
- #24: Problems & Issues #4: Complexity It’s a task to just set up the development environment. I had to... Install virtualisation software. Install FF 3.5 & IE 8. Install, configure & learn to use screen reader. Install browser plugins (Juicy Studio Accessibility, Firefox Accessibility Extension) Keyboard navigation requires complex JavaScript coding.
- #25: From 2008/09 screen reader user survey @ webaim.org, good all-round resource for accessibility info. Remember, to use ARIA you need a browser that both supports ARIA and is supported by a screen reader that also support ARIA . - 75% of respondents update to a new version of screen reader within 12 months. Notice the very low percentage of IE 8 users. So safe to assume that under 50% of screen reader users can leverage ARIA functionality.
- #26: After the last few minutes you might be thinking “why bother”...but... - Browser & screen readers vendors, & JavaScript library developers, are all working hard (in fact competing with each other) to support ARIA. You can use ARIA in your website now (Landmark Roles, Live Regions)
- #27: WAI-ARIA is just one ‘layer’ of accessibility. Using ARIA doesn’t give us an excuse to ignore the wealth of other techniques we should be using to enhance accessibility (principles of WCAG2, etc). Don’t withhold content from users without JavaScript. Use best practice front-end development techniques (semantic markup, Graded Browser support, CSS for layout, Progressive Enhancement, all that good stuff) & layer ARIA on where possible.