W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2012

RE: Updated ISSUE-206 CP

From: John Foliot <john@foliot.ca>
Date: Tue, 21 Aug 2012 18:56:56 -0700
To: "'Maciej Stachowiak'" <mjs@apple.com>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'Edward O'Connor'" <eoconnor@apple.com>, <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Message-ID: <005d01cd8009$6b99e080$42cda180$@ca>
Maciej Stachowiak wrote:
> 
> How about just suggesting some sort of notification of the image,
> without overconstraining what it is? In general, we let assistive
> technologies (or really UA/AT combos) have a lot of freedom in how they
> handle repair of broken content.

Irrespective of the audio cue being provided, I believe that what is most
important is that we communicate via the Accessibility API (and thus most
likely via Accessible Name) that this is an image of suspected and likely
importance, but that no alternative text is provided. We must remember that
not every non-sighted user can actually hear either: how would this manifest
via Braille output devices for example?

By having a reserved keyword for that Accessible Name I suspect some tools
could replace 'word' with 'audio-cue' (I know that Google/ChromeVox are
interested in what they dub "ear-cons" - as opposed to eye-cons), but I
think leaving that to the screen reader (as opposed to the browser) would be
the better choice moving forward. In a Best Case scenario, the 'verbosity'
of this reserved keyword could also be controlled by individual screen
reading tools (likely via user-settings, such as JAWs Verbosity Settings)
and could also be mapped to localization files at the browser level.

> For Safari+VoiceOver, saying "Image"
> might be a good way to handle these in general. But we might want to
> get more fancy - for instance, we could special-case the situation
> where the image has a sensible filename (for example "architecture-
> diagram.png" or "cat.jpg" instead of "IMG17567.JPG"). And I would not
> presume to dictate what is right for other ATs.

I'm not too keen on that idea personally, as it begins to presume the reason
of/for the image, and may be completely off the mark: for example "cat.jpg"
could be a photo of a kitten, a roaring lion, or my friend Catherine... 

The idea of heuristic guessing for alt text has surfaced previously (it's
been a while), and I think that overall this idea is not well liked: you
have a better than equal chance of guessing significantly wrong as you do
guessing correctly; in actual fact the appropriate alt text for your image
might actually be "タイガー"

> 
> BTW, I appreciate that John did research on this question!

De nada Maciej. What is important is that we get this (and everything else)
right from the end-user perspective. I can appreciate Henri and Mike's
perspective on this topic (as developers and maintainers of validation
tools), but without a solution that also does something better for the end
user, I fear that we are not really solving the real problem.

JF
Received on Wednesday, 22 August 2012 01:57:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 August 2012 01:57:27 GMT