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: Ian Hickson <ian@hixie.ch>
Date: Fri, 6 Feb 2009 10:27:20 +0000 (UTC)
To: James Craig <jcraig@apple.com>
Cc: Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
Message-ID: <Pine.LNX.4.62.0902060956540.952@hixie.dreamhostps.com>
On Tue, 3 Feb 2009, James Craig wrote:
> On Feb 2, 2009, at 8:52 PM, Ian Hickson wrote:
> > On Mon, 2 Feb 2009, James Craig wrote:
> > > 
> > > Are you referring to the sentence that starts: "If the image is not 
> > > available or if the user agent is not configured to display the 
> > > image, then…"?
> > > 
> > > If so, that sentence does not address the non-visual equivalent of a 
> > > displayed image. It only addresses the cases of a broken or missing 
> > > image, or the inability to display an image. Those cases are 
> > > necessary but, as far as I can tell, irrelevant to this thread.
> > 
> > Isn't the case you are talking about covered by "if the user agent is 
> > not configured to display the image"?
> Not really. Most assistive technology (like screen readers) works in tandem
> with a capable, modern user agent. For example:
> <img src="foo.gif">
> Assuming the image "foo.gif" is not broken or missing, it will be 
> displayed in the user agent, so the above case does not apply.

The specification is defined from a black-box perspective. From the 
perspective of the audio view, the user agent has images turned off (by 
definition, almost). From the perspective of the visual view, the user 
agent has images turned on. Thus different requirements apply to the two 

The spec doesn't distinguish (and IMHO should not distinguish) between an 
aural view presented by a screen reader reading the output of a screen- 
media browser, and an aural view presented by a speech-media user agent.

> Assuming there is no other markup (like a heading or legend), and given 
> that no alt attribute was provided, the user agent will not be able to 
> determine the alternative text from the markup. At this point, the user 
> agent should be able to make an assumption (hence the request for 
> clarification) about whether or not the image is meaningful or 
> presentational.

The user agent can make that assumption already because the spec defines 
that the image is meaningful.

> The current wording ("the image might be a key part of the content") is 
> ambiguous enough that a user agent cannot make that assumption.

I don't understand why not. Could you elaborate?

> If the wording were more explicit to indicate whether or not <img 
> src="…"> was a meaningful image, the user agent could continue:
> 1. In the case of a presentational image, no additional recovery is 
> necessary, and the default semantics of that element (mainly that it is 
> an image) need not be conveyed to the user.
> 2. In the case of a meaningful image, there are several ways that 
> assistive technology (in conjunction with a user agent) may try to 
> recover.

It could be either, there is no way to know. In a compliant document, it's 
the latter (case 2).

> I might even go as far as to add an author requirement such as, "Authors 
> SHOULD NOT omit the alt attribute if is known to have appropriate 
> alternative text.

The spec already has a number of far stricter requirements. For example, 
in the section on images that represent a phrase or paragraph with an 
alternative graphical representation (charts, diagrams, graphs, maps, 
illustrations), the spec says, of the text that the image represents:

# The text must be given in the alt attribute, and must convey the same 
# message as the image specified in the src attribute.

Similarly, in the section on images that are "a key part of the content", 
the specification says:

# When it is possible for detailed alternative text to be provided, [...] 
# text that can serve as a substitute for the image must be given as the 
# contents of the alt attribute.

> A missing alt attribute indicates that the image is meaningful, but no 
> alternative text is known by the author or authoring tool."

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).

> > Case 3 is covered by the next entry in that list, entitled "If the src 
> > attribute is set and the alt attribute is not".
> > 
> > First, that section defines what this means:
> > 
> > # The image might be a key part of the content, and there is no textual
> > # equivalent of the image available.
> As I stated above, the wording "might be" is too ambiguous.

Reality is ambiguous in this case. We can't legislate away the 
imperfections of existing content.

> > Then, it says what user agents that _do_ support images must do:
> > 
> > # If the image is available, the element represents the image specified by
> > # the src attribute.
> Unless there is alternative text available in the image file, such as in 
> SVG, this is meaningless to assistive technology. I'm not even sure what 
> you're trying to say by the phrase, "the [img] element represents the 
> image." Of course the img represents the image! Isn't that redundant?

The term "available" is defined to mean that the user agent supports the 
image. In the case of a screen reader, no image format is supported, so 
the image is never available.

> > (Extra text in the rendering section will elaborate on this.)

This text is now written by the way:


> > Next, it says what user agents that do _not_ support images must do:
> 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?

I've added a note to make this clearer.

> > This is a pretty detailed set of requirements already.
> You are correct, it is detailed, but it still doesn't define whether or 
> not an image should be treated as presentational if no "caption 
> information" is found.

I don't think there's anything we can say one way or the other here. The 
rendering section suggests providing an icon (visual or aural as 
appropriate) to indicate there is a missing image, but at the end of the 
day there's no way to know whether the author screwed up or not. (The same 
would be true if we had an attribute like noalt="".)

> > Could you elaborate on what your proposal:
> > 
> > > "User agents MAY (or SHOULD) assume images without an alt attribute 
> > > are a key part of the content lacking a textual equivalent."
> > 
> > ...is intended to require?
> Sorry, this should have said, without an alt attribute and without 
> otherwise associated alternative text.

But what does it require? Could you describe a test page that demonstrates 
how to test whether a user agent is complying to this requirment or not?

> 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.

> Perhaps this should just be the last step in the caption info algorithm:
> # 4. If the img element did not end up associated with a heading in
> #    the outline, or if there are any other images that are lacking an alt
> #    attribute and that are associated with the same heading in the
> #    outline as the img element in question, then there is no caption
> #    information; abort *steps 4 and 5*.
> #
> # 5. The caption information is the heading with which the image is
> #    associated according to the outline.
> #
> 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.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 6 February 2009 10:28:00 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC