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

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





--- Comment #18 from John Foliot <jfoliot@stanford.edu>  2010-08-29 19:08:02 ---
(In reply to comment #17)
> > 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? 

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'? 


> 
> > How do AT devices work with aside now?
> 
> I assume by "AT devices", you're thinking of AT software like JAWS or Dragon
> Naturally Speaking or ZoomText (they're not what I'd call a "device")?
> 
> I've not tested; I suspect they don't treat it differently to "div" at the
> moment.
> 
> 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. 

Please, can we be sure to make the distinction between AT and screen-readers
here? 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.. In this case *LACK OF BROWSER SUPPORT* means they
cannot interact with the DOM entry that is the longdesc value. So suggesting
that poor AT support is somehow the culprit here is both false and misleading -
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.

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.

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: until we see full HTML5 parser support it's a 'work-in-progress' element
that relies very much on backwards compat. - (yep, it's a meaningless
container)


> Long descriptions are a perfectly legitimate need, but they're
> hardly top of the accessibility priority list so I wouldn't be surprised if
> implementation dragged years behind the potential offered by (draft!)
> specifications.
> 
> For evidence of low prioritisation, see:
> 
>    * http://www.nvda-project.org/ticket/392
>    * http://www.nvda-project.org/ticket/809

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.

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

Received on Sunday, 29 August 2010 19:08:06 UTC