Re: Investigating the proposed alt attribute recommendations in HTML 5

Hi Jon,

Thank you for summarizing the issues as you see them. Unfortunately  
it is difficult to see how the current draft actually addresses the  
issues you list. I'll elaborate.

On Sep 11, 2007, at 9:17 AM, Jon Barnett wrote:

> There is a Real Problem we're trying to solve.  Since it's not clear
> to me by reading this mess that this problem is understood, I'll try
> to state it clearly.
>
> [... alt text needed for iconic embedded content...]
>
> Sometimes images are not iconic, but are integral to the meaning of  
> a page:
>
> [2] <img src="grand-canyon.jpg" alt="The grand canyon as viewed from
> the east at sunset">
>
> Clearly, that text can't be considered an equivalent for the image -
> can a few words replace the grand canyon?

This seems to place a unreasonable burden on alt text in order to say  
it shouldn't be provided. Perhaps you've never been to the Grand  
Canyon, but the image itself is a poor equivalent for the Grand  
Canyon. Perhaps the alt text "Ce n'est pas la Gorge Grande" might be  
appropriate here as in Magritte's famous painting. An image is no  
more an equivalent of what it captures than the alt text is an  
equivalent for an image — but that's only in the sense you're using  
equivalent here. If I take a trip to the Grand Canyon and place a  
photo journal of my trip online, the photos do serve as an equivalent  
of that trip and so does the alternate text that describes those  
pictures. It doesn't place the reader literally at the Grand Canyon,  
but it tells the story of the trip. That's the only burden we should  
be placing on the alt text in this scenario.

> No, the the presence of the
> image is important.  A screen reader user needs the presence of the
> image announced so that the user knows they're hearing a description
> of a picture and not a random sentence out of context.
>
> So, since JAWS can't really tell the difference between [1] and [2],
> it sounds from your tests that JAWS announces the presence of the
> image.  If it announces the presence of every image [1] gets read as
> "Linked Graphic Home Linked Graphic About Us Linked Graphic Store ..."
>  Does a blind person really need to be taunted with the presence of 5
> or 6 images in a navigational menu?  On the other hand, if JAWS did
> NOT announce the presence of an image, [2] would just be read as "The
> grand canyon as viewed from the east at sunset" - a single sentence
> out of context with no indication that there's an image.

How does the proposal in the draft address this problem? On the other  
hand the proposal discussed within the WG and on the Wiki does  
address this issue[1].

> Since @alt is required by HTML4, we often see authors insert text even
> when it doesn't belong, such as a list of icons accompanied by text:
> [3] <li><a href="..."><img src="home.jpg" alt="Home">Home</a>
> <li><a href="..."><img src="about.jpg" alt="About Us">About Us</a>
> <li><a href="..."><img src="store.jpg" alt="Store">Store</a>
> <li><a href="..."><img src="blog.jpg" alt="Blog">Blog</a>
>
> This, even without announcing the presence of an image, is confusing
> when read as "Home Home About Us About Us Store Store Blog Blog".  So,
> authors are encourages to simply leave @alt blank:
> [4] <li><a href="..."><img src="home.jpg" alt="">Home</a>
> <li><a href="..."><img src="about.jpg" alt="">About Us</a>
> <li><a href="..."><img src="store.jpg" alt="">Store</a>
> <li><a href="..."><img src="blog.jpg" alt="">Blog</a>

Here's where heuristics would  work well. If an author doesn't  
realize the alt can be omitted, the UA can be instructed to avoid  
speaking redundant repetitive phrases. Such icons can also be handled  
through CSS (and it would be appropriate to do so).

> That way, a screenreader knows to ignore the image.
>
> But since authors are allowed to just leave @alt blank, they may not
> bother describing the grand canyon:
> [5] <img src="grand-canyon.jpg" alt="">
>
> Using the logic from [4], the screenreader might think the image  
> can be ignored.
>
> That's the problem the draft attempts to solve.

if that's the problem the current draft sought to solve, it missed  
the mark by an incredible margin. Again, the proposal discussed in  
the WG and included in the wiki does solve that problem [1]. The  
problem is that authors already overload the omission of 'alt' and  
alt='' with so many meanings we can't possibly add these to the  
existence or non-existence of this attribute.

> It distinguishes
> between [4] (a graphic that can be ignored) and [5] (a meaningful
> graphic where the author refused to give any helpful text).

This should be handled just like when an author refuses to close  
their table element with a table close tag. The UA will try to repair  
it, but telling the author that it's valid is not appropriate.

> My suggestion earlier in this thread was to use @title to describe a
> meaningful image so there is some accessible text without implying
> that text is "equivalent" to the image.

I don't see how this suggestion addresses any of the problems you  
just listed. Why would using the 'title' attribute that is supposed  
to contain text of an advisory nature be abetter place for alternate  
text content than the 'alt' attribute? Again, you're treating  
'equivalent' in a way not intended by prior HTML recommendations. Why  
not just prohibit photographs in HTML and tell authors to just use  
the text "go see the Grand Canyon" because there's no way an image  
can be an equivalent for seeing it in person. Documents are never an  
equivalent to what they document. They can be equivalent to something  
only in that they are a representation of something else. They  
document cannot be an identity to that something else. I sense this  
is the way you're using 'equivalent'. That's not how its being used  
in HTML.

> So...
>
>
> On 9/11/07, Steve Faulkner <sfaulkner@paciellogroup.com> wrote:
>> so:
>>
>> <img scr="poot.jpg"> image is ignored
>>
>> <img scr="poot.jpg alt=""> image is ignored
>>
>> <img src="poot.jpg" title="poot"> title is announced
>>
>> <a href="poot.html"><img scr="poot.jpg"></a> src is announced
>>
>> <a href="poot.html"><img scr="poot.jpg" title="poot"></a> title  is
>> announced
>>
>> <a href="poot.html" title="poot"><img scr="poot.jpg"></a> title is  
>> announced
>> (window eyes) src is announced (JAWS)
>
> - In which of these cases is the presence of an image announced?  All
> of them?  Are there cases where JAWS sometimes does announce the
> presence of an image and when it sometimes does not?  Which ones?
>
> - Does JAWS always treat omitted @alt the same as alt=""?  If so, is
> that harmful with the current draft, or is it a reasonable
> "degredation" from the current draft?  Would it be reasonable for a
> future version of JAWS to follow the draft?

The current draft should simply be reverted on this issue. I don't  
see anyway for the 'solution' in the current draft to reach any kind  
of consensus in the WG. The current draft highlights some important  
problems as you did here. However, it fails to address those problems  
in any substantial way. It does instead tell authors that they SHOULD  
omit alt text when my reading of the general view of this WG that  
authors SHOULD NOT omit the alt text. The current draft also uses the  
phrase "when no alternative text is available and none can be made  
available," When can an author not make alternative text available.  
It is the same as saying whenever an author cannot be bothered to  
write the alternative text. Will this make some sites invalid? No  
doubt. However, it does  more damage to tell authors it is  
unnecessary than to simply leave those pages as invalid. What problem  
is solved by simply sayin pages that have no alternative text when  
they should are now valid. Henri has tried to argue that making pages  
invalid for this reason will lead authors to not care about  
validation. Won't authors be able to distinguish between the ideas  
that the page is invalid because its' missing alternative text and it  
is invalid for many other reasons? If an author sees no benefit in  
conformance, then it won't help to just make conformance easier to  
attain.

> If JAWS's current behavior matches the draft (when it announces the
> presence of an image vs. when it doesn't), that great!  But that's not
> the important question to ask.  More importantly: If authors use the
> semantics laid out in the draft (by omitting @alt and using other
> markup for "important" images), does that have harmful side effects in
> JAWS, and can a future version of JAWS follow these semantics?

The current draft does not address the problems you list here so I  
don't think the question is even worth asking.

> Alternatively, is there a better way to solve these Real Problems in a
> way that degrades gracefully and screen readers can implement?  Two
> other suggestions have been @noalt - a new attribute to indicate an
> important image, and specific markup using <figure> for all
> "important" images.  If so, do these solutions solve these Real
> Problems in a way that degrades more gracefully in screen readers,
> text browsers, and other browsing situations where images are not
> loaded?

Yes, I think the previous discussion of the WG actually do something  
to address the problems raised in your message [1]. That proposal  
does not place an unreasonable burden on equivalent text, but it does  
address all of the other problems you list in a much more substantial  
way and in a way that is backwards compatible.

Why not simply provide a blanket statement that says whenever an  
author is unable to comply with the requirements of this HTML5  
specification, they SHOULD NOT do so? This is precisely what the  
current draft does with respect to the 'alt' attribute requirement.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/EmbeddedContentRoleAndEquivalents>

Received on Tuesday, 11 September 2007 23:41:10 UTC