HTML5 Accessibility Challenges

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

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

AlastairC says:

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!

Steve Faulkner says:

@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…