Transcript Slide 1
An Introduction to WAI-ARIA Dan Jackson Web Team Leader City University London About this session 1. What is ARIA? What does it do? 2. Why do we need it? 3. Roles, States and Properties, keyboard navigation, Live Regions 4. Where ARIA we with ARIA?* Problems & Issues 5. Best practice * All my puns are rubbish. Get the acronym out of the way early doors.... Web Accessibility Initiative. Accessible Rich Internet Applications. It’s at ‘Final Call’ draft stage, i.e. it’s not a formal specification (yet). What does ARIA do? W3Cese English “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.” It’s a W3C specification that defines a way to make Web content and Web applications more accessible to people with disabilities. (http://www.w3.org/TR/wai-aria/) 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 Why do we need ARIA? So what’s the problem? 1. Widgets are inaccessible - Assistive Technologies (AT) don’t know what they do. 2. Widgets are rarely keyboard accessible. 3. Content updated using AJAX is not reported to AT. ARIA to the rescue! ARIA provides semantic meaning, dynamic content updates and consistent keyboard support to AT users. Roles States and Properties Keyboard access Live Regions The technical part Roles Roles define widgets and page structure. 2 categories: Landmark Roles Widget and Element Roles 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 Landmark roles Widget & Element Roles To describe GUI widgets, elements common on desktop but not native to HTML. Examples: grid menu progressbar slider tab toolbar tree 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" ariavaluemin="0"> Accessibility isn’t just about screen readers.... Throw away your mouse. 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. 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). 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 Problems, issues: The V-Word ARIA vs. HTML 5 Is it supported? Complexity Will AT users adopt it? Where aria we with ARIA? 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!? Issue #2: ARIA vs. HTML 5 ARIA HTML 5 Landmark Roles New structural elements <div role=”navigation”> <nav> ARIA Properties and States HTML 5 form attributes <input name=”email” aria-required=”true”> <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. 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/ARIASafariaOperaIEFF.html 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) 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. Issue #5: Do Screen reader? Mostly. AT users update? Browser? Questionable. http://www.webaim.org/projects/screenreadersurvey/ ...it’s not all doom and gloom Support is growing. You can use ARIA to improve your website right now. (Landmark Roles, Live Regions) 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. Resources • http://dev.opera.com/articles/view/introd uction-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.