W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2008

Re: some reflections on @alt usage

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 19 Aug 2008 21:35:01 +0000 (UTC)
To: Al Gilman <Alfred.S.Gilman@ieee.org>
Cc: W3C WAI-XTECH <wai-xtech@w3.org>
Message-ID: <Pine.LNX.4.62.0808192112530.14795@hixie.dreamhostps.com>

On Tue, 19 Aug 2008, Al Gilman wrote (reordered slightly for coherence):
> The move to include something of a categorical description when a 
> highest-and-best alternative is not available is (personal opinion) a 
> positive step.  The curly-braces syntax is questionable and under review 
> in PFWG and pros cons and alternatives I expect to be the subject of 
> more comments anon.

Great, I look forward to it.

> > > 1. The two examples offered for when a missing @alt might be the 
> > > highest and best markup available to the encoding sofware are 
> > > ill-chosen. They don't pass accessibility review as exemplifying the 
> > > logical conditions they are supposed to represent.
> > 
> > I don't understand what this means. How do things "pass accessibility 
> > review as exemplifying the logical conditions they are supposed to 
> > respresent"? Could you elaborate?
> I did elaborate.  Elsewhere in the page.  You didn't associate.  Which 
> makes one of my points, sorta.

Ok... but I still don't understand what that point is.

> In the Rorschach test WCAG spells out what you should provide as a text 
> alternative.

Could you elaborate? I haven't been able to find where in the WCAG 
documents it is made clear what could be said that would actually help 
accessibility here.

> > > 2. Don't say that this markup advice is for *important* images where 
> > > you don't know what to provide as a text alternate.  The 'important' 
> > > restriction is not appropriate.  The same markup approach should 
> > > apply for unimportant images where you don't know that they are 
> > > unimportant.
> > 
> > Could you provide an example? When would there be an unimportant image 
> > for which alternative text is required (i.e. it's not decorative) and 
> > for which the alternative text isn't available?
> In the batch-upload scenario, the site wrapping the uploaded photos 
> doesn't know which files are key moments from the vacation and which are 
> useless blurs containing only a fuzzy swipe of the user's foot.  You 
> don't know it's important until you know what is in the image and what 
> it contributes to the story it is embedded in.

In the context of an HTML document, though, those pages are objectively 
important regardless of whether they may be unimportant in the context of 
the wider photoset. They are the "content" of the page, which is important 
by definition.

> > > if we are going to try to address this as a common case, 
> > > unknown-to-be-decorative images should be included and not just 
> > > other unknown-what-to-say images thought to be 'important.'
> > 
> > How can the author not know if the image is decorative or not?
> See discussion of photo-upload scenario above.

None of the photos are decorative in that example, and you know this 
ahead of time, before the photos have even been uploaded.

> You are the ones separating the actor (photo site software writer) that 
> is coining the markup from the other actor, the tourist who understands 
> what is shown in the images.  It is that split of the 'author' into two 
> asynchronous actors that makes this possible. If we had a FrontPage user 
> in an interactive session inserting an image, the story would be 
> different.

I have no idea what what that means. Could you explain it in simpler 
terms? I still don't know how an author can not know if the image is 
decorative or not.

> > > And make it clear that the "human didn't bother" case is included.
> > 
> > According to HTML5, if the human didn't bother, the page isn't 
> > compliant.
> This is statement at variance with the attempt to cover the photo upload 
> case. I don't agree with this interpretation of the draft as posted.

The spec says:

# When it is possible for alternative text to be provided, for example if 
# the image is part of a series of screenshots in a magazine review, or 
# part of a comic strip, or is a photograph in a blog entry about that 
# photograph, text that conveys can serve as a substitute for the image 
# must be given as the contents of the alt attribute.
 -- http://www.whatwg.org/specs/web-apps/current-work/#a-key

That seems pretty cut and dry to me. Could you cite the part of the spec 
that says that "not bothering" is a valid reason to not include 
alternative text? If there is anything that can be read that way, it 
should be fixed.

> > > In particular, most accessibility experts will not agree that the 
> > > photo upload use case is one where the authoring tool could not come 
> > > up with something that is better than nothing.
> > 
> > While this is clearly true (people calling themselves accessibility 
> > experts have stated they do not agree that a site accepting uploaded 
> > photos may not know what the image represents), I do not intend to 
> > pander to accessibility experts. My goal is to make the spec actually 
> > improve accessibility.
> in your own judgement, it would sound like. Your judgement in these 
> matters would be more accurate if you listened more attentively to the 
> institution of the WAI.

With all due respect, I would rather base my judgements on verifiable 
research and on logical arguments than on blanket assertions that seem 

> The identity of the photo-uploader, the date/time when it was taken or 
> uploaded, an image sequence number, any tags attached, and labeling or 
> other text associated with groups it has been included in are 
> significantly helpful to the user.

That information is significantly helpful to all users, and should (and 
is) exposed to all users.

> In the photo upload case there are indeed better things that the site 
> can say than you admit (when considered with a good background in 
> disability access).

Could you elaborate on this? What could be said that isn't already being 

> You seem to be assuming that the use can associate this information 
> correctly with the image.  The world in which the speech-only user 
> experiences a web page is smaller than that.  If the relationship of the 
> "also on the page" text to the image is machine-interpretable, as for 
> example 'legend' on 'figure' then the AT can help the user make the 
> association.  In the absense of such a formal relationship, the 
> redundancy can be more positive than negative.

This is so diametrically opposed to my own experiences that I would need 
significantly more evidence of this to be convinced of it. Do you have any 
research you could show to demonstrate this remarkable assertion?

> Something that "appears somewhere else on the page" doesn't meet the 
> technical requirements for a text alternative, as the user's working 
> memory of what is on the page is limited.

I think this dramatically undersells the user. If a page contains a title, 
and a comment, and an undescribed image categorised as a photo, users 
would have no trouble associating the description comments and the title 
with the photo.

> My personal preference would be to get that info in the DOM in formally 
> specified relationship to the image, and then see what makes sense to 
> put with the image itself that is terse, and serves two functions: 
> inform the user about the image and distinguish this image from others. 

Merely having the image on the page links the information to the image. 
Why is this not sufficient? I do not understand what user interface you 
are imagining that would make this more usable than what we have now. 
Could you elaborate? Why would a sighted user have less trouble 
associating disparate information in a Web page with an image on the Web 
page than a user without image support?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 19 August 2008 21:36:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:22 UTC