Search

An Introduction to WAI-ARIA

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    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.: (site-oriented content, e.g. logo, page title) (central document content) (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? is an input field required? how much of my file upload is complete? 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: or or ? HTML 5 form attributes and states vs ARIA properties and states: or 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.

    1 Event

    An Introduction to WAI-ARIA - Presentation Transcript

    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.
      • 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=&quot;0%&quot; aria-valuenow=&quot;0&quot; aria-valuemax=&quot;100&quot; aria-valuemin=&quot;0&quot;>
        • 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
      • 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.

    + iwmw iwmwiwmw iwmw, 3 months ago

    custom

    317 views, 0 favs, 0 embeds more stats

    Parallel session on 'An Introduction to WAI-ARIA' g more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 317
      • 317 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 1
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    Groups / Events

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved