HTML5 Accessibility - Is it ready yet?
•Descargar como PPTX, PDF•
9 recomendaciones•2,114 vistas
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?
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (8)
Destacado
Destacado (20)
Similar a HTML5 Accessibility - Is it ready yet?
Similar a HTML5 Accessibility - Is it ready yet? (20)
Último
Último (20)
HTML5 Accessibility - Is it ready yet?
- 1. HTML5 accessibility is it ready yet? Steve Faulkner & Hans Hillen The Paciello Group (TPG)
- 2. HTML5 process W3WHATWGC W3C WHATWG
- 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 MSAA Iaccessible2 UI automation AX STK roles states properties interaction + device independent interaction
- 7. Accessibility API Input device browser role=button state=focused value=submit query action=press
- 8. so, is it ready yet? HTML5 accessibility that is????
- 10. long answer is: NOT BY A LONG SHOT
- 11. NIT BY A LING SHIT LING (HTML5) <------ NIT (accessibility)
- 12. AccessibleHTML5 will be a beautiful thing
- 13. HTML5 is a work in progress
- 15. structures
- 16. canvas
- 17. video
- 18. audio
- 19. ARIA
- 20. ‘fallback’
- 22. who are thevillains?
- 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? ? ? ?
- 25. a tale of 2 browsers
- 26. a tale of 2 browsers Opera mini Safari Using VoiceOver
- 27. accessibilityisalways bolted on, sometimes by Browsers ATs CMS/tool developers library developers web developers users more less
- 28. generally speaking,the earlier it is bolted on,themore robust Browsers ATs CMS/tool developers library developers web developers users more less
- 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"> </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
- 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 WRONG
- 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 Demo
- 39. No equivalent
- 40. <nav>
- 42. No equivalent
- 43. <aside>
- 44. <form>
- 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
- 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! Demos
- 49. LEAVE HTML5 ALONE! 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?
Notas del editor
- 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.