HTML5 is the fifth version of the World Wide Web Hypertext Markup Language (HTML). HTML5 accessibility is a work in progress with many details still under development. Currently the browser and assistive technology (AT) implementations are incomplete. HTML5accessibility.com (link resides outside of ibm.com) provides the status of various Web browsers which include support for the platform accessibility infrastructure.  At this time, the Worldwide Web Consortium (W3C) has proceeded with the last call working draft (link resides outside of ibm.com) of HTML5. However, there are often multiple review cycles before the draft is considered complete. This is particularly important as it relates to HTML5 accessibility since most of the browsers have not implemented all of the components that are included in HTML5. The W3C HTML Working Group (link resides outside of ibm.com) continues to work on improving HTML5, but the fight to include accessibility features is ongoing.

Browser support

Currently Firefox has the best HTML5 accessibility support score based on HTML5accessibility.com (link resides outside of ibm.com).

In 2012, there are plans to finish all of the accessibility component mappings for Firefox and the application programming interface (API) mapping layer implementation for the Mac operating system. Work is also underway with assistive technology vendors to ensure assistive technology support is provided.

The status scores and details are available on HTML5accessibility.com (link resides outside of ibm.com).

W3C WAI-ARIA

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is now included in HTML5, so it is part of the normative language, which defines what is required for conformance. Because the HTML5 specification points to the WAI-ARIA specification, this means that WAI-ARIA can be enhanced in the future without making changes to the HTML5 specification. Developers often write custom widgets for Web applications, and the new HTML5 input controls will provide added flexibility for developing custom widgets.

Image of a browser displaying how ARIA works. 20% of the work needed for rich desktop A Cross platform accessibility API Full Keyboard navigation like desktop Ubiquitous adoption Designed to support WCAG 2 and the U.S. 508 Refresh All major browsers providing support
Figure 1. Example of why and how WAI-ARIA works.


WAI-ARIA has become the declarative accessibility API for the Web. Using WAI-ARIA, developers can write applications that are accessible on multiple platforms. WAI-ARIA is increasingly more important for mobile applications and enables the delivery of accessible information technology (IT) across multiple devices.

There is currently work in progress to produce a document that explains how HTML5, including WAI-ARIA, maps to the platform accessibility API layers on each of the platforms. The mapping is extremely important for things like name calculations on elements. The document will describe how the mapping works, and should improve harmonization on all browsers in the future, providing a platform for improved interoperability.

Multimedia = Multi-modal

New media aspects have been added to HTML5, including new video and audio tags. At the onset, the W3C working groups have taken user requirements into consideration when developing the new video and audio tags to address the following disabilities:

The goal is to provide alternatives to the video and audio content, such as:

There are two major formats used to synchronize alternative tracks for multimedia such as video, Web Video Time Text (Web VTT) and Timed Text MarkUp Language (TPM L). TPM L is the current standard used by the broadcast industry today, but it appears that Web VTT may become the actual standard for the Web browser.

Five different types of tracks have been defined:

These tracks are useful for devices, such as talking books, to provide navigation by chapters including a track for metadata. Most of the tracks are intended for use with scripts.

In addition there will be a media controller API inside the browsers. It is an emerging technology that allows users to create their own custom players in the browser, or dynamically synchronize video. This is important as we move toward personalization and context awareness of applications. For example, it provides users with the ability to turn captioning on and off, or switch tracks to turn on sign language.

The following is an example of the HTML5 video tag with associated alternative caption and subtitle tracks:

<video poster="myvid.jpg" tabindex="0" preload="auto" height="240" width="320" controls>
<source src="myvideo.mp4" type="video/mp4"/>
<source src="myvideo.webm" type="video/webm"/>
<source src="myvideo.ogv" type="video/ogg"/>
<track kind="captions" src="myvideo.vtt" srclang="en"/>
<track kind="subtitle" src="myvideo_sp.vtt" srclang="sp"/>
<p>Final fallback content</p>
</video>

Canvas accessibility

Canvas accessibility is the next big development, and is important because it provides 2D drawing that can produce accessible data analytics.

Figure 2 below is an example of the use of fallback content. On the left hand side is a screen shot of two checkboxes labeled “Show As” and “Show Bs”. To the right of that image is canvas standard and WAI-ARIA enabled fallback content representing the two checkboxes. To the right of that is the accessibility API mapping of the checkboxes showing the roles, states, names, and actions, and how it maps to an assistive technology. These elements are keyboard accessible to enable users to navigate the fallback content

This is a long description of the slide: On the left hand side is a screen shot of two checkboxes labeled “Show As” and “Show Bs”. To the right  of that image is canvas fallback content with an standard and aria-enabled checkbox representing the two checkboxes. To the right of that is the accessibility API mapping of the checkboxes showing the roles, states, names, and actions. This is then mapped to an Assistive technology.
Figure 2. Accessible canvas conceptualization (use of fallback content)


There are challenges related to magnifiers, because what is rendered on the canvas is separate from the fallback content. There needs to be a mechanism to provide fallback content to the magnifier to drive visual focus, so two new APIs have been added to the specification; to draw a system focus ring and a custom focus ring. Where a system focus ring can be used in Windows is where a dotted box follows the bounds of the element, based on the path, using the same drawing conventions as the operating system. A custom focus ring allows authors to write their own custom focus rendering. Another new function adds based-to-text metrics so developers drawing focus rings or carets associated with a piece of text will be able to properly position them relative to the text.

Alternative text

Historically there  have been issues with HTML 4 related to text alternatives (often abbreviated as alt text). These issues have yet to be resolved in HTML5, so currently longdesc, and table summary have been removed from the specification. There is a chance longdesc may get added back into the specification.

New figure and figcaption elements have been added to HTML5 so that users can group a collection of images into a figure and create a figcaption. There are extensive author conformance requirements related to alternative text in HTML5. Some of these requirements are prompting the industry to further migrate toward the use of WAI-ARIA for text alternative and descriptions and the plan is to use WAI-ARIA 1.1 to fill the gaps that are evident in HTML5.

Mobile accessibility

Going forward, assistive technology features will become mainstream in mobile. Currently, mobile browsers are in varying states of readiness to provide accessible Web content support. The WAI-ARIA support is incomplete and some of the browsers only target select disabilities. Another concern is the availability of web accessibility test tools, which are currently limited to the desktop.

Many mobile applications are hybrid applications that contain both Web content and native components, which present unique issues that need to be addressed. The key mobile gap is related to the Web content and keyboard navigation. Users cannot respond using the keyboard because full key functionality is not supported by Web in mobile devices with touchscreen interfaces. W3C is starting a new effort called the Independent User Interface (Indie UI) Working Group (link resides outside of ibm.com) to address browser independence for gestures and others user interactions.

In terms of browser and assistive technology support, it appears the large portion of work is planned in 2012 and 2013 using the HTML5 accessibility mapping guide. And there is an extensive undertaking by assistive technology (AT) vendors taking place to adopt the HTML5 API mappings in a future release. However, it is expected that mobile support will lag behind the desktop. HTML5 and WAI-ARIA 1.1 will provide a great accessibility convergence platform as browser and AT support is developed. AT vendors are in various stages of adopting the HTML5 accessibility API mapping.

HTML5 is coming

HTML5 accessibility is a work in progress. While it provides many changes and improvements from HTML 4, organizations are going to have to prepare by reeducating their development teams. 

Full assistive technology support is not expected before 2013. The OpenAjax Alliance (link resides outside of ibm.com) has plans to start working on HTML5 accessibility rules the second half of 2012.