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!
