Re: Investigating the proposed alt attribute recommendations in HTML 5

the word description or any of its deriviatives does not belong in the same 
sentance with alt unless it says don't.  Alt is replacement as far as it can 
be done within its perameters.

----- Original Message ----- 
From: "Steve Faulkner" <sfaulkner@paciellogroup.com>
To: "Jon Barnett" <jonbarnett@gmail.com>
Cc: "Henri Sivonen" <hsivonen@iki.fi>; "HTMLWG" <public-html@w3.org>; 
<wai-xtech@w3.org>
Sent: Tuesday, September 11, 2007 11:51 AM
Subject: Re: Investigating the proposed alt attribute recommendations in 
HTML 5


Hi Jon,

>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 am unsure of what you impying here, who does not think this is a "Real
Problem"?  what is the "what mess" that you are referring to? and what
problem is not understood?

I understand the problem clearly.

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

Just because one is unable to fully describe something does not mean that an
attempt at description should not be made.

Example advice on an appropriate alt text in this case is provided in WCAG
2.0 (
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/Overview.html#text-equiv-all
)

" For such content, text alternatives at least identify the non-text content
with a descriptive label and where possible, some descriptive text. If the
reason for including the content in the page is known and can be described
it is helpful to include that information. "

or from the university of illinois best practices (
http://www.cita.uiuc.edu/html-best-practices/text/)

for photographs "Alt text describes the scene, important relationships
between objects in the scene, important text on signs, the identity of
famous people or places."

or from RNIB (
http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_alttext.hcsp
)

"A brief name or description should be given in the ALT text, and a longer
description of the content of the image given elsewhere"

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

what is your point? And as I have said on several occasions, this behaviour
is not JAWS specific. Yes screen readers such as JAWS could announce images
more intelligently, but omitting the alt attribute does not solve any
problem as there is no way to know whether the alt attribute has been
omitted for a reason or omitted out of neglect.

>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="">

in this instance the image is ignored by jaws and window eyes in their
default configurations and so is
 <img src="grand-canyon.jpg">

and i surmise that this is the default behaviour because of the prevelance
of images without alt attributes on the web. Unless some unambiguous flag is
supplied to assistive tech that an image does not have an alt attribute
because it could not be supplied, then there will be no way for the software
to reliably flag such images as worthy of further investigation and as such
the will be ignored as image without alt attribute is currently.

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

Unfortunately the proposed solution does not solve anything, it just makes
it more likely that authors and authoring tools will ignore the alt.
And besides it has not been demonstrated that this is a "Real Problem" that
cannot be resolved without recourse to making the alt optional.

I have asked twice before (on the HTML WG list) and will ask again, please
provide real world examples (specific URLs) of cases where the alt should be
omitted so that these can be tested with assitive tech and user tested, then
once more results are available we may be able to have a more informed
discussion about what the best solution is.


On 11/09/2007, Jon Barnett <jonbarnett@gmail.com> wrote:
>
>
> Steve,
>
> 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.
>
> On the web, images are used in various ways.  Sometimes, an image is
> iconic and represents text, such as in a menu like this:
> [1] <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>
>
> There is no disagreement that alternate text is correct.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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?
>
> 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?
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Tuesday, 11 September 2007 20:49:43 UTC