HTML5 Accessibility - Is it ready yet?
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


HTML5 Accessibility - Is it ready yet?



What are the features in HTML5 that have the potential to: ...

What are the features in HTML5 that have the potential to:
make it easier for developers to provide a more accessible user experience?
make it harder for developers to provide a more accessible user experience?
Where does WAI-ARIA fit into the HTML5 accessibility story? How can WAI-ARIA fill the gaps in HTML5 UI accessibility?



Total Views
Views on SlideShare
Embed Views



16 Embeds 492 196 151 64 30 21 15 3 2 2 2 1 1 1 1 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • The current HTML5 development process is a hybrid of the W3C and WHAT WG development processes. There are people who prefer one process over the other, but the mixture of these processes makes for better specification outcomes.
  • Most people who are interested and excited by HTML5 are not interested in the politics behind its development.
  • Accessibility covers a range of issues for people with varying impairments including vision, mobility, cognitive and aging.
  • The implementation of new HTML5 element features in browsers affects in particular users who rely assistive technology, such as screen readers, to access web content.
  • For users of assistive technology to be able to access and interact with web content, browser developers need to expose HTML5 features through accessibility applications interfaces and make interactive features operable without the use of a mouse.
  • Each HTML feature has a role, name, state and other property values that need to be hooked into the accessibility APIs by the browser. Assistive technology can then use this information to convey a representation of the feature to users.
  • The big questions are is HTML5 accessibility ready? If not when will it be?
  • HTML5 features are currently either not implemented or not implemented with accessibility support.
  • There is still much work to be done by browser vendors to include accessibility support in their products.
  • Without accessibility support HTML5 is like a fairly ordinary fish with a parasite close by.
  • With accessibility support HTML5 will become a powerful, useful, interoperable, versatile language for the world wide web.
  • HTML5 is not yet a standard, work continues on the standardisation process at the W3C.
  • The developmentof the W3C HTML5 specification and its implementation is a work in progress. While the specification is at an advanced stage of development, there are still issues to be worked out and much implementation work to be done.
  • Which browsers provide good accessibility support for HTML content? In other words which browsers can be used by people with screen readers to surf the web? On Windows Firefox and Internet Explorer. On Mac only Safari.
  • There are not really any villains;Google chrome is not yet accessible on any platform, but they are working hard on providing accessibility support. Firefox works great on windows and Linux, but not on Mac OSX, Safari works well on Mac OSX and iOS 4 but not on Windows. Opera does not have accessibility support on any platform, but provides features that other browser do not, which are useful to a range of people with disabilities who do not use assistive technology. It is also rumoured that Opera are working on AT support, but that has been a rumour for years...
  • One question is, when will browser vendors implement the HTML5 interface elements? Another is when will they implement accessibility support? And yet another is When will they implement in particular the new HTMl5 form controls in a way that developers want to use them and are able to style them as desired. Which ff the major browsers Safari, Internet Explorer, Firefox, Chrome and Opera, will provide useful and accessible support for the new HTML5 user interface features?
  • There is an ongoing debate about bolt on versus built in accessibility. For example adding an alt attribute is considered as ‘bolt on’ because it requires the author to do work to make an image accessible. While a standard HTML button has some accessibility information ‘built in’, but this is not the case in all browsers as this accessibility information has to be bolted on by the browser developer.
  • 3 tweets about Opera mini on the iPhone: I tweeted about my like of Opera mini: “I find Opera mini the best browser for viewing/reading web pages on iPhone.”@mishu70 asks: “@stevefaulkner is it accessible with VO?” @ppatel replies: “@mishu70 No. Opera mini is most certainly not accessible to VoiceOver.”
  • When using VoiceOver, Opera mini is akin to a black screen as it is unusable. The opera developers have not bolted on the accessibility support in Opera mini.
  • Generally more accessibility is bolted on by browser vendors than by other participants in the process.
  • Generally, the earlier accessibility is bolted on the more robust it is.
  • Whoever provides the accessibility information, if its done right the end user is provided with a better experience.
  • The buttons in the Gmail interface look like standard buttons, but are actually coded using a load of nested divs. It is assumed this is done because the Gmail developers could not get the look and feel cross browser, that they desired, from a standard HTML button. It is ALWAYS recommended that standard HTML controls be used over custom controls, but if custom controls are built using HTML elements, it is recommended that the semantics of the control are provided using a technology such as ARIA.
  • ARIA is the Web Accessibility Initiative Accessible Rich Internet Applications specification. With technologies such as ARIA we can move from a mindset that views accessibility as the art of the killjoy, always telling developers what they cannot do, to one of creative inclusivity.
  • This site is a resource to provide information about which HTML5user interface features are accessibility supported in browsers, making them usable by people who rely upon assistive technology (AT) to use the web.It is not intended to dissuade developers from using HTML5 features. Sometimes there are better choices, sometimes developers have to add a little extra to make the feature useful or usable, and other times features have simply not been implemented by any browser or only by browsers that do not yet support assistive technologies. As a consequence it may not yet be practical to use a particular HTML5 feature. Example work around for lack of implementation or lack of accessible implementation are are provided.

HTML5 Accessibility - Is it ready yet? Presentation Transcript

  • 1. HTML5 accessibility
    is it ready yet?
    Steve Faulkner & Hans Hillen
    The Paciello Group (TPG)
  • 2. HTML5 process
  • 3. and then there’s the rest who
    probably don’t care
    photo by Joel bez
  • 4. “accessibility
    is about more than
    screen readers...”
  • 5. ...but in this session we are talking about assistive technology support, if you are expecting more you will be disappointed
  • 6. Accessibility APIs
    UI automation
    + device independent
  • 7. Accessibility API
    Input device
    value=submit query
  • 8. so, is it ready yet?
    HTML5 accessibility
    that is????
  • 9. short answer:
  • 10. long answer is:
    NOT BY A
    <------ NIT (accessibility)
  • 12. AccessibleHTML5
    will be a beautiful thing
  • 13. HTML5 is
    a work
    in progress
  • 14.
    • form controls
    • 15. structures
    • 16. canvas
    • 17. video
    • 18. audio
    • 19. ARIA
    • 20. ‘fallback’
    • 21. ‘text alternatives’
  • whoaretheheroes?
  • 22. who are
  • 23. ?
    when will browsers
    implement HTML5 UI features in a way that developers will want to use them?
    when will browsers
    expose HTML5features via accessibility APIs
    when will browsers
    implement HTML5 UI features?
  • 24. bolt-on
  • 25. a tale of 2 browsers
  • 26. a tale of 2 browsers
    Opera mini
    Using VoiceOver
  • 27. accessibilityisalways
    bolted on,
    sometimes by
    CMS/tool developers
    library developers
    web developers
  • 28. generally speaking,the earlier it is bolted on,themore robust
    CMS/tool developers
    library developers
    web developers
  • 29. but if it’s done right
    it makes no difference
    to the end user...
  • 30. <DIV class="J-K-I J-J5-Ji J-K-I-Js-Zq J-K-I-Js-Zj J-K-I-JW" role=button tabIndex=0
    unselectable="on" act="9" closure_uid_1bjdqs="1012"><DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
    <DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
    <DIV class=J-K-I-KC unselectable="on">
    <DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
    <DIV class=J-K-I-Jz unselectable="on">Report spam</DIV> </DIV></DIV></DIV></DIV>
    ...and no matter what is bolted on by the browser, developers will find a reason to want something else
  • 31. which is why WAI-ARIA is needed
    preaching abstinence does not work
    accessibility = the art of the killjoy
    accessibility = the art of creative inclusivity
  • 32.
  • 33. “So if HTML5 A11Y is not ready…
    WHAT IS!?!?”
  • 34. The answer is simple really…
  • 35. …websites built in the 90's!
    Cause only web 1.0 can be accessible
  • 36. Some HTML5 works tomorrow…
    WAI-ARIA works today!
    Why not use it in the meantime?
  • 37. ARIA Landmark Roles
    Identify and label commonly used , relevant sections on a web page
    Screen readers users can quickly locate these sections and navigate between them
  • 38. Some Landmark Roles actually map to HTML5 Section Elements , some don't
    • <header>?
    • 39. No equivalent
    • 40. <nav>
    • 41. <input type="search">?
    • 42. No equivalent
    • 43. <aside>
    • 44. <form>
    • 45. no equivalent
  • What's with the Question Marks?
    For banner, main, contentinfo roles…
    <header>, <article>, <footer>…
    For each (nested) application or document
    Use as many as you like!
  • 46. And Search?
    Role="search" represents the entire search module
    Hints, instructions, etc.
    Complex search options
    Role Can be set on containers
    <input type="search"> is just the form control
    But, in some use cases they can be equivalent
  • 47. What about Widgets?
  • 48. Well, What about Them?
    Many HTML5 widgets are either
    Not implemented yet
    Not exposing accessibility information yet
    So for now just use ARIA widgets
    They work!
    Do we really have to use ARIA instead of HTML5 elements?
  • 50. Why not do Both?
  • 51. Combining Landmarks
    <header role="banner">
    <div role="search"><input type="search" /></div>
    <article role="main">
    <aside role="complementary">
    <footer role="contentinfo">
  • 52. Combining Widgets
    A bit more tricky
    You either want a working HTML5 widget, or a working ARIA widget
    Modularize your widgets using libraries
    Perform browser sniffing to decide whether to generate an HTML5 or ARIA component
  • 53. In a nutshell
    HTML5 is going to be great
    Until then, use ARIA for an accessible rich UI
    Combine where possible
  • 54. Questions?