Re: null alt text

John Foliot wrote:
> Liam McGee wrote:
> Prior to the release of WebAIM's Survey results last week
> [http://webaim.org/projects/screenreadersurvey/], Accessibility advocates
> would have this debate (surrounding appropriate @alt) every few months (it
> seemed) - with both sides eloquently stating their opinions and ideas.  I
> am guilty of this as well: I have oft advocated using the pattern of
> alt="[Photo - John Foliot]" or alt="[icon - Adobe PDF]" or
> alt="[illustration - bar graph of user statistics]" based upon *my*
> limited research and opinion (and used in all of my development work).
> 
> The WebAIM survey produced some interesting results however - and while
> Jared and Co. want to do some more analysis (and perhaps even reconsider
> the question and it's phrasing for the next survey), they do state: "It is
> clear that there is a disconnect between what evaluators/those without
> disabilities and full-time/disabled screen reader users want." - and what
> the full-time/disabled screen readers generally want is some value beyond
> _null for "Images [used] to enhance the mood or feel of a web page".  For
> actual photos (the one used in the survey was of the White House), 80% of
> respondents preferred "Photo of the White House" (no haiku there!, and
> makes me feel that my pattern suggestion is not that far off the mark),
> while "Identification of logos" was a completely mixed bag of results with
> no clear "winner" (note, I suspect that the results were somewhat skewed
> by the original question which presented 4 "stock" responses, and that
> other options were not accounted for)

:) Yes, sorry, my prose was getting a bit purple... completely agree re: 
the photo, but still not sure about "Images [used] to enhance the mood 
or feel of a web page".

>> Do you reject the idea that alt is co-equal equivalence
> 
> I do, and the survey tends to back me up, but again there remains much
> interpretation to be done.  However, I get a sense that the terse,
> informational 'bite' value of @alt seems to be the overall preference:
> leave eloquence and haiku to @longdesc (listening HTML5 WG?).

Short and sweet alt - agree. But is the purpose to describe an image or 
to replace the function of that image? I'm guessing you are saying the 
former and not the latter. Again, can't shake the feeling that this 
would be better off held in the title attribute - "This attribute offers 
advisory information about the element for which it is set".

> And what of the notorious spacer.gif of old.  Trash-can please.  And of
> purely decorative flourishes?  CSS. It's 2009 for gosh sakes, and alt=""
> needs to simply disappear - if the image is important enough to put into a
> document *inline*, then it is important enough to have an @alt value.
> It's that simple (to me anyway)

I have to admit that I can't remember the last time I used alt="" - but 
do we advise those who are building in sub-optimal markup just not to do 
it? Or that if they are still learning the ropes, then this is how to 
deal with images that add nothing to the meaning of the web page.

Maybe the answer is that alt="" should come with a substantial health 
warning? Perhaps some extension of

http://www.w3.org/TR/WCAG20-HTML-TECHS/F38.html

and

http://www.w3.org/TR/WCAG20-HTML-TECHS/F39.html

is required... maybe to include the caveat from 
http://www.w3.org/TR/REC-html40/struct/objects.html#adef-alt

[While alternate text may be very helpful, it must be handled with care. 
Authors should observe the following guidelines:

Do not specify irrelevant alternate text when including images intended 
to format a page, for instance, alt="red ball" would be inappropriate 
for an image that adds a red ball for decorating a heading or paragraph. 
In such cases, the alternate text should be the empty string (""). 
Authors are in any case advised to avoid using images to format pages; 
style sheets should be used instead."]

Regards to you all, and thanks for putting up with my ramblings

Liam
-- 
www.communis.co.uk

Received on Thursday, 5 February 2009 19:29:10 UTC