RE: 7 November 2000 WCAG 2.0 draft available

Dear Alan,

Thanks for responding.  Would you consider suggesting ALT text for Wendy's
example 2 and 3?  They are the more challenging situations and, in my
experience, make the writing of a substitute (versus a description)
difficult to do effectively.  In principle, I agree with this philosophy
(and, of course, your page that I referenced is focused on the composition
of good ALT content -- and there are plenty of good examples).  It's just
that in practice, _short_ textual substitutes are often simply inadequate.

More comments inline...

> -----Original Message-----
[snip]
> On Tue, 7 Nov 2000, Bailey, Bruce wrote:
[snip]
>> 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.
>
I agree.  I think Lynx's behavior is perfectly satisfactory.  I am curious
if anyone thinks differently!  If not, our examples should certainly have
Lynx in mind!
[snip]
>> 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.
>
I understand your analysis.  It is a little tricky since a graphical UA will
usually have to make a choice as to render the TITLE or ALT, especially when
there is no white space (or other text) between the link and the graphic --
as is often the case.  Ex:
<A href="page2of2.html" title="More Information"><IMG
src="images/r_arrow1.gif" alt="Next Page"></A>

I would choose NOT to make the situation more complicated!  I would also
point out that the default behavior of both IE and Lynx is quite acceptable
for the above example.  Lynx renders the ALT content.  IE displays TITLE (as
a tool-tip) in preference over ALT when the two choices are present.  Both
browsers allow one to "preview" the link before selecting it (and both use
the link TITLE attribute, if present, for this).  For its part, the JFW
screen reader will expose both ALT and TITLE content upon command.  How
would adding <Q>title="Right Arrow"</Q> to the image improve this scenario?
[snip]
-- 
Bruce Bailey

Received on Tuesday, 7 November 2000 13:50:40 UTC