Re: Investigating the proposed alt attribute recommendations in HTML 5

On Tue, 11 Sep 2007 16:17:58 +0200, Jon Barnett <jonbarnett@gmail.com>  
wrote:

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

This is not a good example. Real users (like Dave noted, since he is one)  
generally prefer a short alt that allows them to move on. If they need a  
feel for the picture, then it should have some kind of fuller description  
associated, that they can choose to listen to, such as you can do with the  
longdesc attribute.

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

Generally, people choose to have this information, just in case the image  
doesn't have alt text and sounds bizarre. because on the real web, that is  
still a vast amount of real content.

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

You can set up this horribly complicated software to announce or not all  
kinds of things in all kinds of ways. A simpler example is that people  
swap their punctuation settings regularly. (A reason why people who can  
read braille often prefer it to speech is because of the precision. The  
fact that speech systems are thousands of euros cheaper than high-quality  
braille systems, are built into the computer, and that only about a  
quarter to a third of blind people can read braille, are major factors in  
the prevalence of speech synthesis).

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

If yu have a longer description available, in case the user wants to know  
(most descriptions of the grand canyon are pretty asinine and pretty  
similar - heard one grand canyon, you've nearly heard 'em all, so skipping  
it isn't necessarily a bad thing) then this can be a great solution. The  
image is announced, but you don't have to listen to a description that is  
long enough to get in the way without being enough to really give you  
anything. If you want to read the long description you can, or you can  
skip it.

This is like a caption that is four lines long for such an image, but  
really just says more about what the grand canyon looks like in the photo.  
It doesn't take long for most people, but you often decide it is a waste  
of reading time, and you want to get the the bit where they are racing  
down the canyon... or the really good, serious description of the  
atmosphere that the picture tried to capture. Either way, the caption is  
overkill.

> That's the problem the draft attempts to solve.  It distinguishes
> between [4] (a graphic that can be ignored) and [5] (a meaningful
> graphic where the author refused to give any helpful text).  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.
>
> 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?

No it doesn't, and it would be harmful to do so (there are times when you  
decide you need something, and alt="" is a sometimes-useful method of  
deciding).

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

It could, but that assumes that authors will follow the draft. One of the  
few things you can predict in accessibility is that, in many cases,  
authors won't follow the specification well, so anything that relies on  
authors doing the right thing is likely to fail. The question is what the  
failure conditions lead to - the principle of handling errors.

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

@noalt relies on people marking something we already know they don't mark,  
so seems doomed to the same problems we already have. figure is more  
interesting - it meets a different use case, although it is compatible in  
my mind with the existing markup (which in general you need to support for  
plenty of years to come). It provides for the valuable case where people  
are going to put in a useful caption that, in many cases, serves the same  
as alt, meeting the visible metadata principle. There are cases where it  
would make sense to supress alt, and announce the figure and its legend.  
In some of these, users might ask for a longer description, the alt, or  
"any kind of repair that might help", in others they won't need it.

In particular, I think that important images - the ones that convey the  
central meaning of a page - are not well served by these mechanisms, but  
that images which are relevant and interesting but not so essential are  
the ones where figure has a valuable role to play.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)

Received on Thursday, 13 September 2007 18:23:50 UTC