W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Need differentiator between "no alt text provided" and "no alt text necessary"

From: James Craig <jcraig@apple.com>
Date: Fri, 6 Feb 2009 11:47:10 -0800
Cc: Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
Message-Id: <D9F7A07D-BE30-4C22-AB78-DD6ADBFE2DBE@apple.com>
To: Ian Hickson <ian@hixie.ch>
Ian Hickson wrote:

> The spec already says:
>
> # If the src attribute is set and the alt attribute is not
> #   The image might be a key part of the content, and there is no  
> textual
> #   equivalent of the image available.
> #
> #   [...] the user agent should display some sort of indicator that  
> there
> #   is an image that is not being rendered [...]
>
> ...which seems like a more accurate statement (since we can't know  
> that
> the author didn't know alternative text, it might just be that the
> document is non-conforming).

Then the easiest edit might be to change:

"the image might be a key part of the content"

to:

"the image is a key part of the content in a conforming document"

or perhaps to:

"the image is a key part of the content in a conforming document, and  
might be a key part of the content in a non-conforming document"


>> Perhaps this is where the confusion lies. If "user agents that do not
>> support images" is intended to include "user agents that do support
>> images but are being accessed by users who cannot see the visual
>> representation of those images", then this sentence should be  
>> rephrased.
>
> I don't understand. In what sense does a speech browser (such as the  
> aural
> view provided by a screen reader) support images at all?

All screen readers convey the semantic role "image" (that the  
alternative text is a representation of an image on the screen, not  
just text on the screen).

Also, many low-vision users have some visual acuity and access the web  
using a screen reader in conjunction with a visual browser, sometimes  
using a screen zoom utility or with a modified color/contrast display.  
In this scenario, the screen usually follows the screen reader cursor  
in some way.


>> FWIW, I'm using "alternative text" in the same way you're using  
>> "caption
>> information."
>
> The two are very different! Alternative text, or replacement text,  
> is text
> that can be substituted in instead of the image without unduly  
> affecting
> the page's meaning. Caption information is text that describes the  
> image
> but it not particularly helpful in and of itself and is no  
> substitute for
> having the image.

True, but in the absence of defined alternative text, if caption  
information can be discovered, most assistive technology will use that  
caption information in lieu of no alternative text, so the user  
experience is rarely different.

>> Perhaps this should just be the last step in the caption info  
>> algorithm:
>> …
>> 6. If no caption information can be determined from the previous  
>> steps,
>> user agents MAY assume the image is a key part of the content  
>> lacking a
>> textual equivalent in the document, and MAY use other recovery
>> mechanisms to attempt to determine the text equivalent.
>
> The spec already says:
>
> # User agents may also apply image analysis heuristics to help the  
> user
> # make sense of the image when the user is unable to make direct use  
> of
> # the image, e.g. due to a visual disability or because they are  
> using a
> # text terminal with no graphics capabilities.
>
> Is this what you are looking for? I can make it more general if that  
> would
> be helpful, e.g. adding "or other recovery mechanisms" or something.

Not necessary. "Image analysis heuristics" suffices, but I'm more  
concerned with the first part of #6, now trimmed and quoted here:

>> 6. If no caption information can be determined from the previous  
>> steps,
>> user agents MAY assume the image is a key part of the content  
>> lacking a
>> textual equivalent in the document…

This addition and/or the edit listed above ("the image is a key part  
of the content in a conforming document") would appease my concerns.
Received on Friday, 6 February 2009 19:47:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC