An Introduction to WAI-ARIA
•Download as PPT, PDF•
4 likes•3,726 views
Parallel session on 'An Introduction to WAI-ARIA' given by Dan Jackson, City University at the Institutional Web Management Workshop 2009, University of Essex, 28 - 30 July 2009. See http://iwmw.ukoln.ac.uk/iwmw2009/sessions/jackson/ and http://lanyrd.com/2009/iwmw09/srfxk/
![About this session ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to An Introduction to WAI-ARIA
Similar to An Introduction to WAI-ARIA (20)
More from IWMW
More from IWMW (20)
Recently uploaded
Recently uploaded (20)
An Introduction to WAI-ARIA
- 1. An Introduction to WAI-ARIA Dan Jackson Web Team Leader City University London
- 11. Landmark roles
Editor's Notes
- 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
- 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).
- 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 .
- 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.
- 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.
- 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.
- Roles States and Properties Keyboard access Live Regions
- Roles define widgets and page structure. Broadly fall into 2 categories: Landmark Roles Widget and Element Roles
- 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
- 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
- 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
- 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.
- 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.
- (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 .
- 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
- The V Word ARIA vs HTML 5 Still in draft & being developed. Is it supported? Complexity (coding, testing) Do AT users update?
- 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.
- 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?”.
- 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.
- 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 .
- 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.
- 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.
- 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)
- 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.