HTML5 semantics and accessibility

 

This  is a comment I made on the article Pursuing Semantic Value The author requested that I post it separately, so I have.

Stating the obvious

Semantics are not just about accessibility, accessibility is not just about assistive technology. But semantic information (name, role, states and properties) carried by HTML elements and attributes is integral to making content on the web accessible, especially for those who rely upon assistive technology to access and interact with web content.
Historically and currently accessibility support for HTML features in browsers lags behind other facets of feature implementation, and unfortunately accessibility support is not taken into account when browsers announce support for a feature. Which is why we get claims about HTML5 structural elements being implemented in browsers. What is actually meant, pretty much, is that visual styling has been implemented.

HTML accessibility support

Where there are clearly defined semantics already available via acccessibility APIs for new HTML5 features, it is easy for browsers to implement the support and no excuse for AT to not understand and convey the appropriate information to users.
The accessibility implementation and semantics of particular HTML5 elements is still being worked out. This is mostly due to the semantics, from an accessibility support perspective, not being well specified or specified at all in the HTML5 specification. The HTML to accessibility API implementation guide is intended to help with this, but it is still in early development

hgroup – an element in search of a cowpath

For example, the hgroup element is a mess. Why? because it is an element in search of a cowpath. As currently sepcified it does not provide a useful semantic to assistive technology users, in fact it does the opposite, it removes potential information about subheadings/subtitles/taglines etc, by forcing implementers to collapse the subheading semantics into the parent heading. That is why hgroup is at risk in the W3C HTML5 specification, with 5 detailed proposals to either abolish or replace it.

header – useful or not?

Another example is the header element from discussions with browser and AT implementers, it is considered that the header element does not add much value as it does not provide anything that currently available semantics does not. To understand why, it is useful understand the ways in which screen readers can expose HTML element information to users. As a consequence it may well not be implemented in browsers or AT.

HTML5 outline algorithm

In regards to the outline algorithm, Jeremy states “The new outline algorithm in HTML5 will make life a lot easier for future assistive technology” which suggests that he is not aware of the implementation of the outline algorithm in JAWS 12/13, unfortunately the current implementation can actually undermine users ability to navigate and understand document structure. Note, also it does not take hgroup into account.

figure and figcaption – meaning in the pipeline

The figure and figcaption elements currently have no semantic meaning. This is partly because the semantics are not defined in accessibility APIs and partly because the available role semantics and labelling relationships have not yet been implemented in browsers. There is active work going on to change that. I wrote a post about the challenges of defining the semantics. At the W3C TPAC meetings last week we discussed the addition of a figure role in ARIA 1.1. There is also moves afoot to add a figure role to the iAccessible2 API, and Firefox are making progress (Firefox bug) on the implementation of the labelling relationship for figcaption/figure and role implementation for figcaption.

Browsers have an integral part to play in accessibility support

For a long time, the refrain from certain quarters has been, screen readers don’t support feature X its been in HTMLX for ages, F#@King screen reader vendors. They are an easy target. Part of what HTML5Acessibility was set up to do was draw attention to the browser vendors role in providing accessibility support. I suggest that browser implementation is an integral aspect of HTML accessibility support, without it there is not chance of robust, interoperable access to web content for AT users. Take a look at the debacle with longdesc, AT for the most part cannot be relied upon, and should not need to be relied upon to implement accessibility features, without the browsers doing their part.

HTML5 a work in progress, get involved!

HTML5 is still a work in progress, but it’s at a stage now where significant changes must not be handed down from upon high, the community must have the opportunity to be involved in affecting change. Involvement in the W3C HTML working group provides that opportunity, get involved!

HTML5 semantics and accessibility
Steve Faulkner
Mon, 14 Nov 2011 15:18:22 GMT