RE: 7 November 2000 WCAG 2.0 draft available

Hello,

On Tue, 7 Nov 2000, Bailey, Bruce wrote:

> Hopefully this won't start an unending thread on writing good ALT
> text...

I don't intend it to either, but while agreeing with much of what you
say, I think there are a few points that are worth making...

> Lynx renders ALT inline.  If the image is not associated with a link, there
> is no indication whatsoever to distinguish body text from ALT text.  (Is
> this a bad thing?  If so, what UA checkpoint does this violate?) 

The benefit of a browser rendering ALT text seamlessly is that it
makes it possible for an author who is aware of this, and who desires
the text rendering to be seamless, to make it so.  When they want
punctuation, they can supply it.  If a browser supplied its own
delimiter, then there would be no way for the author to get rid of it.

The disadvantage of a seamless rendering is that authors who are not
aware of it can produce surprising results, as in the two "howlers"
which you quoted from my article (but only the first was at fault by
lacking punctuation: I'll discuss the fault in the second one
shortly). However, it's a fact that some indexing robots also produce
these same results, so I think I'd come down on the side of educating
authors into these matters, rather than trying to have browsers
automatically supply some kind of delimiter in their rendering.

> I aim for a middle ground for ALT content -- since often a true "textual
> equivalent" is not possible without a longer description. 

This is certainly true, but one should keep in mind that the ALT
attribute is only one of the available attributes (along with TITLE
and LONGDESC).  

My pages are now out of date in that they offer extensive discussion
about the original ALT attribute, and much too little about the
others; but these developments should mean that there is even more
reason to reserve the ALT attribute for alternative text that performs
the _function_ for which the image was intended; and even less reason
to mis-use it, in general, for a mere visual _description_ of the
image (except in the rare instances where that really is the adequate
textual _substitute_).

And _that_ is the mistake that had been made in the second example
which you quoted from my page, "Oldtown University arms Physics
Department".  The University's arms had been used as a logo for the
purpose of identifying the University. And therefore the alternative
(text-mode) for the _function_ of the logo would have correctly been
"Oldtown University", not "Oldtown University arms".

If and when the arms are used for the purpose of bringing their visual
design to the attention of the reader, then quite a different approach
is called for.  Yes, it's a compromise: the text cannot supply every
nuance which the graphical design can do, and if one tries to make it
so, then all this peripheral detail is going to distract from the main
purpose of the page, rather than enhance it.  So, that's what LONGDESC
can do much better.

> Example 1.  A short label:  A right arrow icon is used to link to the next
> slide in a slideshow.  The text equivalent (ALT) is the word "next".
> Accessibility could also improved by including the title of the next slide
> in the TITLE attribute of the link.

Agreed.  However, this is a subtle one, since there are TITLE
attributes in HTML available on both the IMG tag and the A HREF which
encloses it.  Theoretically, the TITLE attribute should supply
additional information about the resource to which it is applied:
which I take to mean that the TITLE on the IMG should convey
additional information about the image itself, while the TITLE on the
A HREF should say more about the linked resource to which the A HREF
refers.

It remains to discuss what browsers ought to do with those attributes,
I mean how to present them to the reader in an appropriate and useful
way.

all the best

Received on Tuesday, 7 November 2000 12:58:12 UTC