[Bug 10455] Mint a describedby attribute for the img element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455





--- Comment #22 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-30 11:26:51 ---
(In reply to comment #17)

On 29 August 2010, at 19:08, John Foliot wrote:
> > > We don't want a link visually available, as I discussed in my earlier
> > > scenario.
> >
> > You might not, but other developers might.
>
> So then options and choices are a good thing, right?

Not all choice comes for free, however.

> Just as overtly mandating browsers on UI requirements (and the relationship
> of diminishing returns that invokes) so too with content authors! There are
> many voices at the table of any large project, and why should the art
> director take the back-seat to the accessibility guy? What happens when the
> art-director is able to over-ride the accessibility guy because of 'marketing
> considerations'?

Same thing as what happens when the browser art-director is able to override
the accessibility guy because of "marketing considerations" - some users lose
out as accessibility is shunted to some hard-to-find extension or bolt-on
attribute.

> > What's the import of your question? A lot of AT still does nothing at all with
> > "longdesc", and obviously no AT does anything with the proposed "describedby"
> > attribute. 
> 
> AT can include technology such as speech-recognition that allow mobility
> impaired users (quadriplegics for example) a means to interact with their
> computer, or head-mice and other alternative switches, or screen magnifiers,
> one-hand keyboards, etc.

I know. But asking how these hardware devices work with "aside" now as opposed
to asking about how software like Firefox or JAWS works with it doesn't make
sense to me, so I assumed Shelley must mean software AT.

> So suggesting that poor AT support is somehow the culprit here is both false
> and misleading

I didn't mean to suggest that.

> poor browser support to date has been the #1 reason for lack of active pick-up
> of @longdesc, not that it is some-how a flawed attribute.

I'd say poor user agent support and expert discouragement by WCAG and its
popularisers provided negative feedback to a lack of supply (authors writing
long descriptions) or active demand (users requesting long descriptions). I
include the whole collaborating ecosystem of browsers, addons, AT software, and
search engines under the rubric of "user agent". How far arguable flaws in the
design, like encouraging alternate text to be placed in an external document
(not merely hidden) subject to rot or like having a name that did not include
"href", contributed to the problem is hard to judge.

> As far as screen-reader support goes for @longdesc, it is actually very good,
> with market leaders JAWS, WindowEyes and Hal/Supernova providing support today.

It's better than it was, but I don't think this list contradicts my claim that
"A lot of AT still does nothing at all with 'longdesc'". Note the absences of
VoiceOver and Orca, for example, which mean there are whole platforms where
this doesn't work.

> As far as the semantic value of <aside> (or any of the other newly minted
> landmark elements in HTML5) AFAIK no technology today really does anything
> with it

Same would apply to a newly minted "describedby" attribute. Indeed, given poor
discoverability of both "longdesc" and "aria-describedby", anyone who wants to
*guarantee* availability of long descriptions to all users had better stick to
links and same-page content, even if they also use these other features.

> One screen-reader's choice in approaching missing functionality is hardly an
> indication of trends. Using this alone as justification we might as well remove
> all the Web Forms 2.0 stuff from HTML5, as only Opera today supports it. This
> is a poor argument IMHO.

I'm not using the deprioritization of "longdesc" as a justification for
removing anything; I'm explaining why it's unrealistic to expect AT software to
do much useful with "aside" yet.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 30 August 2010 11:26:55 UTC