Following up the discussion on Accessible drag and drop using WAI-ARIA, I think HTML5 may be a huge win for accessibility. HTML4 was filled with good intentions, HTML5 should be filled with good implementations.

HTML4 became a W3C standard 11 years ago. By now we should have plenty of implementation experience with the standard, user agents, web developers, and authoring tools and what has actually made the Web more or less accessible. Ideally there should be an audit of all the HTML4 features for their impact on accessibility, whether they were designed for the purpose or not.

We also have extensive implementation experience. Accessibility was central to the design of Opera from the very beginning and part of the company culture, but that doesn't mean every initiative was a success. Other browsers and tool makers should have learned something the last decade as well. Accessibility enjoys considerable goodwill among developers, most want the Web to be accessible, but to turn good will into good products first we need to make the implicit knowledge explicit, what failed as much as what succeeded and why it failed. …

Accessibility in the browser

The most successful features were the ones people weren't even aware of being accessibility features, they just worked.

Many features added complexity. This is not necessarily a bad thing, but simpler features will always be preferred. Sometimes this meant making the features optional, for special interest only. If you don't need it, you don't notice it. The problem is that you wouldn't necessarily notice it even if you needed it, and more more insidiously the feature dropped from view of most Opera developers and slowly the usefulness of the feature deteriorated, it didn't take advantage of newer functionality (or vice versa), it grew more buggy, and finally it could be removed for being broken.

Integration with assistive tools caused similar problems. Ideally extra tools shouldn't be needed for the same reason that optional features are risky. Any external tool risks obsoletion because it isn't used by the vast majority of users or developers. On the other hand the browser makers couldn't put in the extra effort needed to make a good special-interest product. I am not saying that Opera+Voice couldn't in principle replace a speech reader (though our implementation couldn't), but we wouldn't be as good at it as specialists. The principle is that specialists would use the available programming interfaces to fulfil the additional needs.

This leads to the problem of incompatible models. Even if the programming interfaces were good enough, a speech reader would use an operating system model, as would the browser outside the document window, while what is inside the window would use a web model. They don't work quite the same way, and while the browsers try to bridge the gap, there will be cracks. On a smaller scale there are other conflicting models that makes presenting the many disparate components as a seamless whole to the user very difficult indeed.

What is outside the browser window (or widget) is mostly outside the domain of HTML, and outside the domain of the web application developer. Within the window the web developer is king, but browsers are also user agents that should have the user's accessibility and usability needs in mind. The needs of the web developer and the user may not coincide.

As mentioned the user override > web author > browser defaults cascade is an attractive model. It isn't sufficient to make this work, but we would have a conceptual framework for how to manage accessibility conflicts.

What could HTML5 do for us?

First of all I am an adherent of minimal markup, the author/developer should code what he knows/wants to present to the user, and the user (through his agents and tools) should specify what he needs. Any further markup is not only superfluous but more often than not harmful for accessibility. It is as likely that the well-meaning author will code in a way that will reduce the minority user's ability to interact with the content as that the code will enhance that user's abilities. More code means more problems. It is better to appeal to the user's laziness than to his charitable desires.

Annotative assistance

Laziness means letting the author do what he wants to do directly and easily. This is one reason why longdesc and even alt failed, and that the HTML3/5 element figure is more likely to succeed, but still may fail. The amount of markup for figure is considerably higher than for the alt attribute, but if this means less coding overall it is a worthwhile tradeoff. The figure element also gives another valuable piece of information. As a user with low image access (i.e. using Opera Mini), the most important clue to me is whether a particular image or animation is purely decorative (can be skipped with purely aesthetic loss), illustrative (helps understanding, but not essensial), or critical (the purpose of this page is to show the illustration). You wouldn't know if a figure is illustrative or page-critical, but it is unlikely it is purely decorative. In other words a figure would be more important to the user than an img. In situations with fallbacks (like with object) we don't know if the fallback is functionally equivalent to the preferred media object.

It could also be understanding who would be best placed to do annotations, and their motivations. If the author somehow could be persuaded that it is in his interest to give the reason for the illustration, like with figure, others may be better motivated to telling what the image/audio/video actually is about that is useful for those who can't see or hear them. There have been a number of iniatives and specs for how to do this, but so far this hasn't been simple or convenient to the annotator or particularly useful to the recipient or indeed to anyone except those that are pushing viagra to the public.

Baseline and enhanced functionality

Why should the author have to care about accessibility at all? Ideally he shouldn't have to, the user agent and assistive tools should do that to make sure that what the author coded is optimally presented for the user.

Sometimes the user agent simply doesn't have enough information to be able to do a good job. Except under limited circumstances the UA (plus tools) cannot say what is the content of an image or what role it has in the document. To be able to present the image as something else than an image it will need extra markup.

It is possible for a UA to present a document in ways adapted to the user and not coded for by the author. Opera's Fit to Width or even Opera+Voice are examples of that. The reason why a UA can do this is because the web standards make it possible. A well-functioning UA has enough information to run web applications well, but in general does not have enough information to make equivalent functionality
analogous to the equivalent presentations it can do. This I see as the as-yet unfilled potential of HTML5 and partilarly the web applications part.

For (keyboard, but by extension also voice) accessible drag and drop I proposed a division into baseline and enhanced support. Baseline support is what the UA ought to do, but may not be doing at the time of writing. In a way this is fixing shortcomings in the browser or in the specs. Baseline support wouldn't differ from one application to the next. All of them would have a need to select a drag and drop source and commence the actual dropping (with a keyboard, touchscreen, or voice there may not be an actual dragging involved), and tell the user about the result.

The enhanced support would be the features specific to a particular implementation, one would be different from the next. Drag and drop might have different use in a web game than in an online shopping application.

This baseline/enhanced separation is useful for the access cascade as well. Today there are many misconfigured scripts that due to wrong, missing, or outdated information make wrong assumptions about the user environment and create accessibility problems. The web author shouldn't have to make baseline code, but supporting libraries may make up for browser bugs, while the user should have the option to disable these library scripts if the browser support is indeed good enough (or maybe even disable specific malfunctioning libraries).

Enhanced scripts on the other hand assumes the browser support is there, natively or through a library script, but tries to make the experience more attractive. The default assumption should be that the author knows what he is doing, but sometimes these enhancements interfer with other user needs. For this reason it would be more natural for user overrides to take the form of temporal overrides on a case-by-case basis rather than a blanket override for baseline support.

The same line of argument goes for other functionality like for instance a new! improved! HTML4 accesskey replacement. Baseline support means browser support for going to author/spec-designated elements of the document through means available to the user, including the keyboard. The enhanced support would be the actual interaction. The cascade would here be that the author would assign key labels to the different elements, overriding the browser default (e.g. the browser might assign S to the next section element), which in turn could be substituted by the browser on behest of the user (e.g. the device has no S key).