HTML5 Accessibility Challenges

Posted on Friday, 28 January 2011 by Steve Faulkner

It has been claimed that HTML5 will do a lot to improve the accessibility of web content and web based applications. In theory this is true. The introduction of new form controls in HTML5 is promising, because developers will have to do less bolting on of accessibility information themselves, as it will hopefully have been bolted on by the browser vendors.

The current accessibility support implemented in browsers lags behind their implementations of the sexy new features themselves. These are still early days in the implementation of HTML5 features, so lets keep our fingers crossed that Google,  Apple (Safari on Windows) and Opera will get their acts together to provide at least a basic level  of HTML support in their browsers for assistive technology users. Equally it is hoped  Mozilla, Apple (Safari on Mac) and Microsoft will strive to have their rate of accessibility support match their rapid implementation of the new HTML5 features.

Information about accessibility support for implemented HTML5 features is available at www.HTML5accessibility.com.

The challenge further extends to standardizing the implementation of accessibility features. To this end some people including myself have started work on a document at the W3C called the HTML to Platform Accessibility APIs Implementation Guide (early draft).

An issue that the implementation guide is being designed to help avoid is differences between browsers about how and what information they convey to users of assistive technology. For example, Firefox and Webkit currently have differing ways of providing labels for form controls when using text from the HTML5 placeholder attribute, this divergence will cause issues for both users and authors as there is no clear way to provide a text label that will be uniformly presented to users regardless of browser.  As a consequence it is planned to include information in the implementation guide on what and how to use the content of elements and attributes to provide text labels.

Details of the current Firefox and Webkit form control labeling issues:   HTML5 placeholder attribute tests


About Steve Faulkner

Steven is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains www.HTML5accessibility.com

Comments

  1. I was just thinking about HTML5accessibility.com, it’s a great status indicator / resource for tracking the browser’s progress.

    Something that might make it even better is adding the WAI-ARIA attributes/aspects that the HTML5 spec doesn’t cover.

    Thinking about the role=”dialog” brought it to mind, as it’s something that as a developer, it would be good to know what the support is like for the different thing I might add, whether it’s HTML5 or WAI-ARIA.

    As WAI-ARIA is pasting over current cracks, it wouldn’t need to include things that are in HTML5, and hopefully they would decrease in time.

    Even so, it’s a lot of stuff to track, so it’s only a suggestion!

  2. @alastc

    Would like to do that as I have done quite a bit of testing on ARIA support previously. Its just a matter of having the time…

Comments are closed.

Recent Posts

See all posts in the blog archive

Thank you a million times over. We got exactly what we wanted, when we were told we would get it, at the price we were quoted, and far more valuable than we expected. I wish all our vendors were this effective and professional.

Mark Stender, V.P. Finance and Business, Pearson