A number of issues are being debated in accessibility circles at the moment. These primarily revolve around how browsers and assistive technology interpret and represent HTML semantics via accessibility APIs and to the end user, and how this is affected by the use of CSS style rules.
The wild west
It feels as if understanding how browsers implement accessibility is like the wild west, in many respects it’s uncharted territory, unlike the specification of mainstream implementation of HTML, being specified and documented in explicit detail in HTML5. browsers implementers and AT implementers pretty much do their own thing, all acting in good faith, but without co-ordination or co-operation. This leads to inconsistencies across implementations and deviations from the subset of accessibility support implementation that is specified.
Specification of accessibility support not needed
A while back the editor of the HTML5 specification Ian Hickson made the following statement in reference to the HTML to Platform Accessibility APIs Implementation Guide a document that is being developed in an attempt to nail down HTML accessibility implementation details:
In fact, the proposed document is unnecessary. Vendors have not shown an inability to read the existing normative specifications, and the text does not help authors or readers of the specification.
The problem being is that “existing normative specifications” do not provide details or guidance on many aspects of how accessibility support in browsers or AT is currently implemented or how it should be. There is the WAI-ARIA 1.0 User Agent Implementation Guide which is a good attempt at specifying how ARIA should be implemented, but this covers only ARIA, a subset of what needs to be specified.
HTML to Platform Accessibility APIs Implementation Guide
This document that I am currently editing along with Cynthia Shelly from Microsoft, is attempting to provide details on how to implement the rest of what is now known as HTML5. It’s in it’s infancy, but recently the ongoing work has been given a major boost through the support for its development by Adobe Systems. Along with continuing support from The Paciello Group it means that I will have dedicated days each month for the next year to devote to the editing of the specification.
CSS effects upon semantics
As noted earlier, there has been discussions of late on how CSS rules
affect HTML semantics. I think developers are fairly aware, for example
that using display:none on content means that it will be
hidden from all users (of CSS supporting browsers), including assistive
technology that sits on top of the browsers, while content shifted offscreen
will still be available to screen reader users. But there are other CSS
related effects that are worrying and confusing developers, such as the
use of display:block on table elements which removes all the table semantics in some browsers and display:table on non table elements
which turns the elements into a table. The effects of these seem
counter intuitive since the mantra of CSS as the presentation layer and
HTML as the semantic layer, is widely taught.
If you are interested in discussing, researching and documenting the CSS accessibility issues, join the newly formed W3C CSS Accessibility Community Group.
A non interoperable web is a non accessible web
Currently we have accessibility layer implementation inconsistencies across browsers and assistive technologies, we have a lack of understanding of how features are implemented and a lack of documentation of accessibility features. This makes it harder for developers, implementers and most importantly end users. This situation will not change unless we work together to document and specify this stuff and seek implementation consistency across browsers and AT. A non-interoperable web is a non-accessible web.
