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.
Update 22/02/2015: hgroup is obsolete in HTML5
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.
Update 22/02/2105: A header element that is not a descendant of an article or section element is exposed with a banner role (as per HTML5 implementation requirements) in all modern browsers, except Internet Explorer.
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.
Update 22/02/2015: The outline algorithm is still not implemented in browsers and the JAWS implementation was removed in JAWS 14.
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!
Comments
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.
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:
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.
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.