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 TPGi 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.
Comments
Steve, you’re my only hope. Glad you can dedicate time here.
Thanks Dave, I think it’s going a bit far, but appreciate the sentiment.
Thanks for driving this important issue. As David says – we need you.
One area you might want to consider is dynamic behaviour (or perhaps not if you want to remain sane). It’ takes some concierable effort to clearly define the events (or messages) that get fired when something changes When working in the relatively narrow scope of Firefox and AT-SPI for Jambu, I soon found there was no documentation of the type and order of events to expect when things changed. For example if a light box pops up or a menu is pulled down. This I didn’t know what was a bug or what was just open to implementor choice (the later is a recipe for disaster in my view)
I was mainly concerned with XUL which defines UI elements with fairly static and constant behaviour., but it was still an issue. With HTML, even with ARIA the problem is likely to be worse as the possible events are much more variable depending on the exact markup and JS behaviour used to make that menu (say).
UML sequence or activity diagrams would be a good tool for this.
Anyway this is not meant to belittle the work yo uare doing. Far from it, it is a really important partsof properly defining what I tend to call the ‘full accessibility stack’.
Hi Steve, as the legendary Rich Schwerdtfeger pointed out to me recently, we have barely scratched the surface, and it needs a concerted effort from all of us to do the specification of the accessibility layer justice. I am just waving the flag, as I think its an important that has been sorely under realized in the past. If you (or anybody) has any interest in collaborating on this work help would be warmly welcomed.
Thanks Steve for the overview of this important issue and for the work you and Cynthia have done on the implementation guide which is amazing. I have a feeling that, sadly, many developers are not even aware of accessibility APIs. They do things like providing image alt attributes without understanding the hows and whys of why they need to do it, so perhaps it is not surprising when it comes to display:block and display:table there can be some confusion (apologies for the tortured sentence). Anyway, next year I will have a little more time and would like to answer your call to get involved.
Recently, I’ve been thinking of the accessibility community as being in the middle of a trio of groups: the academics, the developers, and the designers. One of the reasons that communities like Accessify Forum grew and became so helpful was because they essentially acted as a W3C Guideline translation service for those developers and designers concerned about accessibility but who found W3C documentation impenetrable. I can’t say I’ve spent a lot of time looking at W3C documentation recently, but I doubt things have changed a great deal. So, from my point of view, such Implementation Guides are imperative to ensure accessibility features get implemented in a sane and consistent manner, whether it be by web developers or browser manufacturers.
Sorry, that should read “I can’t say I’ve spent a lot of time looking at W3C documentation recently […]”
fixed!
Dammned good article. Industry needs reliable standard reference implementation definitions and when they don’t come by W3C because some folks there simply see no need for norms (because for “everybody in industry is sooo clever, I can follow the do-nothing approach”) others have to do the job. Exactly this kind of thinking has bestowed the oh so similar CSS support implementations in browsers in the past. Acid3 put some shame on this for everybody out there to compare the differences and oh wonder, as a result, the browsers became compliant with each new version. We need an similar ACCAcid test out there 🙂