[html4all] Article by Catherine: Feedback on accessibility concerns in HTML5

[Jason White]

On Thu, Sep 20, 2007 at 09:19:15AM +0100, Joshue O Connor wrote:
 
> Interesting proposal. Is this along the lines of some possible uses of
> the <figure> or <object> elements? A closer association of the image and
> its alternate or long description would be a good thing IMO (in fact it
> could be that closer bindings with any element/attribute and their
> associated content is a good thing, especially if it give various user
> agents more control over how that content is rendered, however I am
> assuming that closer bindings can lead ultimately to this and I may be
> wrong). To get around the users  stated concerns about reading out the
> @longdesc contents (however it is bound to the element) by some user
> defined preference which could be set in the screen reader preference.

Having the description or alternative included in the document at least avoids
the possibility of broken links, to which @longdesc is subject. It also makes
copying the alternative easier, i.e., one doesn't have to bring along a
separate HTML document for each image that warrants a detailed explanation.

XHTMl 2.0 has solved the problem in two ways.

1. IMG is now a container element, the content of which can serve as an
alternative to the image.

2. The SRC attribute is available for a wide variety of container elements,
the contents of which can again serve as alternatives to images referred to
via @src.

The IMG element is retained for backward compatibility only.

Both of these, in my opinion, are well engineered solutions. Why should HTML 5
reinvent the wheel when XHTML 2.0 has an elegant, practical and largely
backward-compatible solution already? This is a rhetorical question. HTML 5
should follow the lead of XHTML 2.0 in this and other areas.

> 
> This kind of control of how the screen reader outputs content in HTML
> documents is pretty standard and is a case of user defined preference.
> Some key could be pressed by the user if they wish the @longdesc content
> to be read out (maybe the enter key, rather like it currently is)
> however my biggest problem with current implementation of @longdesc is
> that a new browser window or tab (IE 7/Firefox) is opened. I would like
> to see the contents of @longdesc (or whatever the new implementation is)
> rendered behind the scenes by the browser, and buffered within the OSM
> or maybe in future iterations of screen readers which not longer use the
> OSM could inject the attribute contents into the DOM and they can then
> be called by the user when the wish. Basically some way of by-passing
> the current, 'load content in new browser window' model, so the user has
> to navigate tabs (which is however not as bad as having to manage
> multiple browser windows.

Orca, for example, doesn't use an OSM at all. Instead, it relies entirely on
an accessibility API to expose the user interface of the application. This is
in turn supported by Mozilla (and possibly other user agents in the future),
which of course have full access to the DOM, the styling of the document, and
any other pertinent aspects. At this point, only MS-Windows-based assistive
technologies still retain the concept of an OSM.