HTML5 semantics and accessibility

Posted on Monday, 14 November 2011 by Steve Faulkner

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 specified 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.  As part of working out how the semantics of these new elements could work 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!


About Steve Faulkner

Steve 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 HTML5accessibility

Comments

  1. Many thanks for the article, however I am a little confused. Are you suggesting use of headers (h#) are useful to AT users or not? I realise there are many forms of AT, but if I may make a comment about just screen readers: I know some screen reader users who never use the header elements for navigation purposes; but on the other hand, I know others who skip down pages via the headers or regularly pull up the list of headers on the page and use these as the main way of skimming the content. My feeling is that if the inclusion of a feature is useful to at least some and not detrimental to others, then overall it should be considered useful.

  2. Hi Roger,

    I am referring to the new HTML5 header element not h1-h6 elements. As specified the header is a container for a heading, as such it is redundant:

    A header element is intended to usually contain the section’s heading (an h1–h6 element or an hgroup element)

    The only situation when it offers a differentiated semantic in practice, is when it is used in the same situation as the ARIA role=”banner” landmark.

  3. I was hoping that HTML 5 would introduce some kind of generic heading element that would eliminate the need for page authors to specify heading levels. It could be more like the LEGEND element for FIELDSETs. For example, you could hav a DIV that contains the main content of the page and it’s first element could be an H with the page title in it. Then if that DIV contains other DIVs with their own H elements, browsers and ATs could logically treat them as H2s. And any sub DIVs of those, would have Hs that would be treated as H3s, etc.

    One of the benefits of this is for componentization. It’s great to be able to have reusable content on your site, but trying to work out the heading levels dynamically can get really crazy. Page authors should just be able to specify what the heading is for a particular piece of content and then let the browser or AT figure out how it relates hierachically to the other page elements.

    Plus, this would help eliminate the common practice of page authors using the various heading levels just to make the font size bigger or smaller.

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

I‘d like to take this opportunity to thank you all for your great business and for your flexibility during our contract amendment. Your people are sensational.

Ray Douha, Sr. UI Planner, State of Minnesota