- Leonie Watson – Nomensa – @LeonieWatson
- Steve Faulkner – The Paciello Group – @stevefaulkner
See more here: HTML5accessibility.com (link repeated below)
HTML 5 Accessibility: Where’s it at?
- Humor: You laugh now, wait till you join the HTML working group (!)
- Steve talked about getting people to join the working group.
Where’s all the excitement?
- Probably the mobile space.
- HTML is being used heavily in that area.
- BUT…all the work is still being done on PCs and workstations.
- …and, the best level of support is still on desktop browsers
HTML5 Spec is BIG
- As a developer though, you don’t need to know everything in the spec.
- A ton of it is for User Agent and browser implementations.
- Leonie: if you read it front-to-back, you’ll go crazy
- Stuff in spec now is either in the process of being implemented, or HAS been implemented by at least one browser manufacturer.
- A great deal of stuff is stable (like the venerable <p></p> tag), but much of it is now.
- ARIA live regions (assertive) drove JAWS users nuts, so it was pulled from the spec.
WEB TECHNOLOGY STACKED
Stack includes a ton of technologies, and all these things are married / integrated together. However, it’s a pretty messy integration and a difficult step for technologists.
HTML5 MAKES USING STUFF EASIER (taken directly from slide)
- New semantic structures (header, footer, article, etc.)
- New UI controls (as opposed to HTML4’s limited controls, which encouraged custom widget and plug-in development)
Leonie commented on the challenges to people with disabilities needing to use custom widgets and elements.
NEW UI CONTROLS = POTENTIAL ACCESSIBILITY IMPROVEMENTS
- Date and Time input
- Local Date and Time Input
- E-mail input
- Month input
- Number input
- Range input
Leonie: support for these new elements is spotty. IE9 has best support among the various screen readers (NVDA has very good support, JAWS is pretty good too)
- Browsers need to implement the new controls.
- Browsers need to implement accessibility suppor for the new controls.
- …and really, the 2 should not be separate, but they are..
Many of the controls you see in desktop OSes will be gotten “for free” with the new browser controls like sliders, progress bars, etc. That’s why it’s important that the browsers implement them quickly.
- + input device support
- roles, states, properties, interaction
Browser has to provide accessibility to the AT in a robust way. There’s a mistaken view that AT is holding up web development…this is false. It’s the browser implementations that are.
Steve reviewed a good slide showing how the API looks, using mechanical typewriter and old telco switchboard. This was actually a very apt visual description of the state of the browser / AT interaction environment.
- Screen shot of the “can I use” web site: http://caniuse.com/
- A good snapshot of what elements each browser supports. (PAUL NOTE: if you haven’t already, I highly recommend you check it out.)
- …or, more accurately, when will the CSS hooks be implemented to allow flexible, atomic styling of control and their sub-elements?
- Eventually the controls will have all the semantic elements “built in,” which will make developers’ lives much easier.
- Browsers are implementing these controls, but developers can’t use them the way they want to use them.
Slide showing examples of audio and video elements (widget controls). These will really catch on when AT can use the embedded controls.
Slide showing new structural elements in HTML5
- JAWS and NVDA are neck-and-neck in their support of the new structural elements
- Navigation with landmarks is now akin to “taking in the page at a glance”
MATCHING FEATURES TO SEMANTICS
- Example: <figure></figure> element allows definition of an image or any piece of content.
- JAWS and Firefox is the only AT/Browser combo that implements the <figure></figure> tag well
- This stuff doesn’t just “happen out of the box,” they need to be implemented appropriately.
Slide showing Accessibility API Mapping
- HTML4, HTML5, WAI-ARIA, MSAA, MSAA+UIA Express, UIA, IAccessible2, etc.
See more here: HTML5accessibility.com
3 replies on “HTML5 Accessibility Support”
[…] Notes from Paul Schantz […]
I personally intend to bookmark this specific
post, “HTML5 Accessibility Support | Paul Schantz” on my
personal web page. Will you mind in the event Ido it?
Thanks a lot ,Callie
Not a problem, please do so.