ALT attributes considered harmful to accessibility
Jukka K. Korpela
attributes themselves that are harmful but the recommendations to use them.
And naturally everyone has to use an ALT attribute for every img element,
every area element, and every input type="image". But my point is that this
is of no use, or is of worse than no use, if the attribute value is not
_adequate_. And in reality, most ALT attributes on Web pages are useless,
or worse than useless. I'm afraid that e.g. the howlers discussed at
http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html#howlers
are rather typical of the actual use, not just shocking examples.
(Maybe not quite so if you count only those actually written by human
beings. But attributes like alt="mksdy.gif (5379 bytes)" are a reality too,
and they fully satisfy the "validation" criteria of many accessibility
checkers.)
An element's ALT attribute should not be decided by considering the element
in isolation. (But such considerations are what people actually make, if
they react to recommendations to use ALT for all elements.)
Rather, an author should think how he would write the page if images (or a
particular image) are not available. In fact it is best if he actually does
just that, writes the page first without images! (With existing pages, the
situation is different of course - it has to be a thought experiment.)
Then the addition of images is to be considered so that the page keeps
working in no images mode too. Sometimes an image _replaces_ some text.
Here's where we get to using ALT: if the text is quite short and contains
no markup, just turn it into an ALT attribute value. Otherwise e.g. move
the text to a separate page and try and find a nice way to refer to it with
a link near the image, e.g. in an image's caption text - and aim at being
able to use ALT="" without preventing access to any information. Naturally,
ALT="" is to be used to purely decorative images. And finally, there are
images that have content that cannot be described in words, such as a
picture of Mona Lisa; then say that, and name the image in the ALT text so
that it becomes obvious that the ALT text is not meant to be taken as such
but as a reference to essentially visual information.
Of course, this is ultimately what many people (including me) have kept
saying. My mild provocation was meant to ask whether we should say things
_this_ way, rather than starting from "use ALT for every image...". After
all, all communication fails, except by accident, and when it accidentally
fails to fail, the part that gets through is probably the first main point
that you make. That is, people will learn just the formal rule, and start
misapplying it.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Eric Jarvis
>
> Of course, this is ultimately what many people (including me) have kept
> saying. My mild provocation was meant to ask whether we should say things
> _this_ way, rather than starting from "use ALT for every image...". After
> all, all communication fails, except by accident, and when it accidentally
> fails to fail, the part that gets through is probably the first main point
> that you make. That is, people will learn just the formal rule, and start
> misapplying it.
>
I don't think that is an argument for altering the formal
rules...it is an argument for better teaching of the
process of web design...and better understanding of how
one should use a framework of rules as the foundation of
good practise rather than as something you test against
when you've finished
--
eric
www.ericjarvis.co.uk
"the alternative to seeing things in black and white
is to see them in full colour"
Alan J. Flavell
> I don't think that is an argument for altering the formal
> rules...it is an argument for better teaching of the
> process of web design...and better understanding of how
> one should use a framework of rules as the foundation of
> good practise rather than as something you test against
> when you've finished
Indeed. Sadly, I can no longer find the original perceptive comment
which I'm sure I read on the W3C mailing lists somewhere, nor can I
correctly attribute it: from memory it was something like "think of
the alt text and the image as alternative ways of representing
content".
cheers
Stewart Gordon
> OK, now that I have your attention, I can tell that it's not the ALT
> attributes themselves that are harmful but the recommendations to use them.
When I saw the subject line, I first thought, "What are you on about?",
then a moment later figured that you meant "ALT attributes that are
considered harmful to accessibility", discussing this particular
subclass of alt attributes. Now I see what you really mean.
> And naturally everyone has to use an ALT attribute for every img element,
> every area element, and every input type="image". But my point is that this
> is of no use, or is of worse than no use, if the attribute value is not
> _adequate_. And in reality, most ALT attributes on Web pages are useless,
> or worse than useless. I'm afraid that e.g. the howlers discussed at
> http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html#howlers
> are rather typical of the actual use, not just shocking examples.
I see. If you haven't already seen it, witness some of the pages listed
at http://webtips.dan.info/images.html#HallOfShame. Witness also the
inadequate alt attribute or two found, ironically, on
http://www.jeffglover.com/ss/savvy04.php.
> (Maybe not quite so if you count only those actually written by human
> beings. But attributes like alt="mksdy.gif (5379 bytes)" are a reality too,
> and they fully satisfy the "validation" criteria of many accessibility
> checkers.)
Meaning ... that they don't generate an error, but also don't suppress
such hand-check warnings as "check that your alt attributes are adequate"?
Guess it's time a regulation were passed for WYSIWYDGs to do default the
alt attribute to something like "I'm a lazy web designer who can't be
bothered to fill in the alt attributes for my images".
> That is, people will learn just the formal rule, and start misapplying it.
I think the main problem is that people learn the fact that alt
attributes are required, but not learn how they're supposed to be used.
The common misconception that tooltips are the purpose is perhaps just
one of these problems.
I still laugh at David Dorward's sensible comment to someone else's
silly question at
http://groups.google.co.uk/groups?selm=b28me4%24kas%241%24830fa79d%40news.demon.co.uk
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
on the 'group where everyone may benefit.
Headless
>Naturally, ALT="" is to be used to purely decorative images.
I've always wondered why. Of course alt should be used on non decorative
images and particularly hyperlinked images, but what's the argument for
making alt="" mandatory for strictly decorative images?
Headless
Chris Morris
In browsers like lynx:
no alt attribute => [IMAGE] or similar
alt="" => {nothing}
In w3m, however, alt=" " may be a better option - it tends to display
alt="" as [{filename}] and alt=" " (as you'd expect) as a space. You
can turn this off, but then you lose any display of images without any
alt attribute as well - I can't find a mid-point option.
So, I prefer alt=" ".
--
Chris
John C. Ring, Jr.
A user-agent has no way to know if the lack of ALT makes sense for a
particular image, or if the author was simply too lazy to add an ALT where
needed. The ALT="" convention permits the user-agent to reasonably assume
that showing NO alternate content on that image is appropriate, where the case
of a missing ALT attribute is more likely to be a sign of a lazy and/or
under-informed HTML author, hence displaying a placeholder makes sense since
the image MAY have been important to the content.
Not a perfect solution, but one used by user-agents since there are far fewer
excellently HTML authored documents on the web then "tag soup" documents.
Stephen Poley
wrote:
alt="" means: 'this is a decorative image, containing no information'.
A text browser will insert no text.
omitted alt means: 'I'm not going to tell you whether this image
contains information or not: guess.' A text browser will typically
insert [IMAGE] or the name of the file, so that the reader knows there
is something there.
Does that help?
--
Stephen Poley
Barendrecht, Holland
http://www.guymacon.com/ "02@spamcop.net Guy Macon
Chris Morris wrote:
>In browsers like lynx:
>no alt attribute => [IMAGE] or similar
>alt="" => {nothing}
>
>In w3m, however, alt=" " may be a better option - it tends to display
>alt="" as [{filename}] and alt=" " (as you'd expect) as a space. You
>can turn this off, but then you lose any display of images without any
>alt attribute as well - I can't find a mid-point option.
>
>So, I prefer alt=" ".
Does the behavior of these various browsers changen whe you also
add title= or longdesc= to the tag? If so, does that chnage
your recomendation?
--
Email: guymacon+PUT YOUR OWN NAME HE...@spamcop.net <br /><html><head>
</head><body><a href="http://www.guymacon.com/resume.html">Electrical
engineer</a> for hire: Los Angeles/Orange County CA USA, 714-670-1687
<br />See resume at: http://www.guymacon.com/resume.html</body><html>
Chris Morris
> Chris Morris wrote:
> >In browsers like lynx:
> >no alt attribute => [IMAGE] or similar
> >alt="" => {nothing}
> >
> >In w3m, however, alt=" " may be a better option - it tends to display
> >alt="" as [{filename}] and alt=" " (as you'd expect) as a space. You
>
> add title= or longdesc= to the tag? If so, does that chnage
> your recomendation?
It doesn't change in either case, at least in w3m or lynx (not tested
it in other browsers). Though why a purely decorative image would
need a longdesc (or perhaps even title) attribute I'm not sure...
title="" might occasionally be useful for stopping a single space
tooltip appearing in browsers that fall back to alt if there's no
title, but it's such a small issue that I don't know if it's worth it.
--
Chris
David Dorward
> I still laugh at David Dorward's sensible comment to someone else's
> silly question at
>
http://groups.google.co.uk/groups?selm=b28me4%24kas%241%24830fa79d%40news.demon.co.uk
... must ... start ... to ... use ... spell ... check!
--
David Dorward http://david.us-lot.org/
"You cannot rewrite history, not one line."
- The Doctor (Dr. Who: The Aztecs)
Headless
>alt="" means: 'this is a decorative image, containing no information'.
>A text browser will insert no text.
>
>omitted alt means: 'I'm not going to tell you whether this image
>contains information or not: guess.' A text browser will typically
>insert [IMAGE] or the name of the file, so that the reader knows there
>is something there.
These are valid practical considerations based on the current situation.
From a theoretical perspective specifying alt="" for decorative images
seems superfluous to me, comparable to specifying title="".
Headless
Alan J. Flavell
> Though why a purely decorative image would
> need a longdesc (or perhaps even title) attribute I'm not sure...
I think you loaded the die against that by the way you asked your
question. Surely the proper question here is "in what situation might
it be useful to have an empty (or white-space-only) ALT text, and yet
provide a TITLE and/or LONGDESC?"
Consider for example:
<img src="foo-logo.png" ...> Welcome to Foo Corporation
For normal readers, the logo does nothing more than to reinforce
the identification of Foo Corporation. There may be nothing useful
that an ALT text can add to this situation, and so, in this context,
ALT="" could be appropriate[1]
However, a text-mode reader might nevertheless be interested to hear
what this logo consists of, by a short description in a TITLE or even
in some cases with a LONGDESC.
> title="" might occasionally be useful for stopping a single space
> tooltip appearing in browsers that fall back to alt
Quite so, if no title were otherwise appropriate.
[1] Curiously, although the WAI guidelines positively recommend
ALT="", the Bobby checker (which I thought was supposed to be based on
WAI guidelines) rejects both ALT="" and ALT=" ", and only declares
itself content when one resorts to ALT=" " or equivalent. I'm
far from happy with that. (Noted the comment about w3m, of course.)
--
I agree
> A: top posting
>> Q: what's the most irritating thing on Usenet?
Chris Morris
> On Tue, Mar 4, Chris Morris inscribed on the eternal scroll:
> > Though why a purely decorative image would
> > need a longdesc (or perhaps even title) attribute I'm not sure...
>
> <img src="foo-logo.png" ...> Welcome to Foo Corporation
Point taken. Though at the moment neither lynx, links or w3m seems to
support either TITLE or LONGDESC, so it's still a bit theoretical.
> the Bobby checker (which I thought was supposed to be based on WAI
> guidelines) rejects both ALT="" and ALT=" ", and only declares
> itself content when one resorts to ALT=" " or equivalent.
It seems quite happy to accept all three equally.
http://www.dur.ac.uk/c.i.morris/bobbytest.html
Or do you mean the offline version?
--
Chris
Alan J. Flavell
> Point taken. Though at the moment neither lynx, links or w3m seems to
> support either TITLE or LONGDESC, so it's still a bit theoretical.
Indeed
> > the Bobby checker (which I thought was supposed to be based on WAI
> > guidelines) rejects both ALT="" and ALT=" ", and only declares
> > itself content when one resorts to ALT=" " or equivalent.
>
> It seems quite happy to accept all three equally.
Good news, thanks. When I tried it not so long back, it rejected even
the precise example which the WAI offer as good practice.
From what you say, it seems that they've fixed it. Thanks.
http://www.guymacon.com/ "02@spamcop.net Guy Macon
On my page at http://www.guymacon.com/resume.html I have two images
(three really, but I am rewriting it with the center image replaced
by text) The rightmost image is pure decoration, and adds nothing to
the content. The leftmost image seems like it might benefit from a
description but I can't think of any text that works as a replacement
rather than as a description. What attributes should I apply?
Jacqui or Pete
http://www.guymacon.com/ "0...@spamcop.net> says...
--
What goes around, comes around;
As ye Sow, so shall ye Reap.
Unless you're Onan, of course.
Hannu Kauppinen
> the alt attribute to something like "I'm a lazy web designer who
> can't be bothered to fill in the alt attributes for my images".
I guess that the programmers of different editors have a great role in
changing the attitude towards alt (and title) attributes. As Jukka
mentioned, currently at least some editors include the name and size of
the picture to the alt attribute. Many editors think, that this is the
purpose of the attribute and thus fail to see the problem associated.
My proposal for the editor programmers would be, that they would not
provide any information to the alt attribute. Instead they could ensist
that a user either enters something to the alt-field or selects the
"decorative purpose only" option (in which case the editor would include
alt=""). Furthermore the editors should make a difference between alt
and title attributes so that the user knows for which purposes they are
used and thus raise the level of websites authored with these editors.
This change could have a double effect as many learn html by looking at
mark-up written by someone else. If the number of well authored pages
will increase, the probability, that a 'newbie' will learn the right way
in the first place, increases.
- Hannu
Jim Ley
<fla...@mail.cern.ch> wrote:
>On Tue, Mar 4, Chris Morris inscribed on the eternal scroll:
>
>> Point taken. Though at the moment neither lynx, links or w3m seems to
>> support either TITLE or LONGDESC, so it's still a bit theoretical.
>
>Indeed
but other text mode browsers do, I'm using my IE in text mode now *,
and it has support for both, in fact even without modifications the
alt as replacement, title as tooltip works pretty well. I'm sure
Mozilla provides similar benefits.
Jim.
* A bit silly I guess as shared internet cafe traffic doesn't make
much difference if I disable images, when everyone else is happy
getting whatever junk.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Tim
> Rather, an author should think how he would write the page if images (or a
> particular image) are not available.
Even that approach isn't very universal. Though I'm sure that the
problem is really due to yet another dumb idea by browser builders.
For instance, I have seen browsers *not* show the ALT text, when you've
instructed it to not show images. Which means that pages where an
author has gone to the bother of making images an optional alternative,
but that the images actually formed part of the structure, the page
makes no sense.
e.g. Using a nasty example:
<p>Return to the <a href=""><img src="home.png"
alt="home"></a> page.</p>
Renders as: Return to the page.
--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
Stewart Gordon
<snip>
> For instance, I have seen browsers *not* show the ALT text, when you've
> instructed it to not show images. Which means that pages where an
> author has gone to the bother of making images an optional alternative,
> but that the images actually formed part of the structure, the page
> makes no sense.
How about sharing with us the identity of some of these browsers, so we
know to avoid them?
Jukka K. Korpela
[Regarding browsers that do not show the ALT text, when you've
instructed it to not show images:]
> How about sharing with us the identity of some of these browsers, so we
> know to avoid them?
In an important sense, Internet Explorer is one. By default, it truncates
ALT texts to the size that fits into the dimensions specified by width and
height attributes, if present. Since it includes an icon of a broken image
into that area, it is quite possible that it does not display the ALT text
at all, even if it is short. What authors can do is to omit those
attributes for small images with nonempty ALT texts.
There's also at least one purported speech browser that completely ignores
IMG elements, which is a very bad move of course. It would not be
reasonable to require that authors take such problems into their
consideration.
Alan J. Flavell
> > How about sharing with us the identity of some of these browsers, so we
> > know to avoid them?
>
> In an important sense, Internet Explorer is one. By default, it truncates
> ALT texts to the size that fits into the dimensions specified by width and
> height attributes, if present.
By default, that's true. Like quite a number of IE options, the
default settings seem to me to be an inappropriate choice.
In addition to the points which you made, discerning users could (I'm
basing this on Win IE 5.5) be advised to visit the Tools->Internet
Options->Advanced menu, and enable "always expand ALT text for
images".
> There's also at least one purported speech browser that completely ignores
> IMG elements, which is a very bad move of course.
When I tried it, IBM HPR reacted in a crazy way to (client-side)
imagemaps: it announced the presence of the imagemap, but otherwise
ignored the contents of the map. Thus, it basically wasted the user's
time by telling them that there was something there which they
couldn't use. This behaviour was even documented in the writeup!
("documented as broken", DAB, as we used to call it).
Minimal correct action IMHO would be to offer the ALT texts of the
areas as if they were links.
> It would not be reasonable to require that authors take such
> problems into their consideration.
Point taken, though there are some common browser shortcomings for
which the WAI suggest author-provided workarounds.
cheers
Daniel R. Tobias
> By default, that's true. Like quite a number of IE options, the
> default settings seem to me to be an inappropriate choice.
This is the normal situation with Microsoft software... for instance,
Outhouse... er, I mean Outlook, can almost (though not quite) be made
into a passable mail and news program with careful reconfiguration, but
the default settings flout lots of standards and conventions.
--
== Dan ==
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/
Andy Mabbett
J. Flavell <fla...@mail.cern.ch> writes
>("documented as broken", DAB, as we used to call it).
Apt, given the piss-poor implementation of Digital radio in the UK...
--
Andy Mabbett
Women are only able to visit Kuwait's stock exchange on a mezzanine floor
called the "Ladies Trading Floor". In Iraq, women can participate fully in the
surprisingly booming Baghdad stock exchange. Guardian 4 Feb 2003.
Nick Kew
at the keyboard of "Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:
>> How about sharing with us the identity of some of these browsers, so we
>> know to avoid them?
>
> In an important sense, Internet Explorer is one. By default, it truncates
> ALT texts to the size that fits into the dimensions specified by width and
> height attributes, if present.
That's the ALT bug. It was introduced in Netscape 3, and has been slavishly
imitated by many browsers since then.
Early browsers did an adequate job. Decent modern browsers do it better.
But there's a lot of terrible stuff between.
--
Nick Kew
Available for contract work - Programming, Unix, Networking, Markup, etc.
Tim
>> For instance, I have seen browsers *not* show the ALT text, when you've
>> instructed it to not show images. Which means that pages where an
>> author has gone to the bother of making images an optional alternative,
>> but that the images actually formed part of the structure, the page
>> makes no sense.
On Thu, 06 Mar 2003 10:31:44 +0000,
Stewart Gordon <smjg...@yahoo.com> wrote:
> How about sharing with us the identity of some of these browsers, so we
> know to avoid them?
Mozilla 1.0 and Netscape 6.2 don't, on Win98SE (here, at least), whether
or not the image also has a title, or dimensions (though, in the case of
having dimensions, a "blank" space is left).
They appear to totally ignore IMG elements, when you're not "loading"
images, rather than simply not "loading" the referenced images.
(Just a note about my prior "nasty" example, the browsers exhibit that
behaviour when there actually is an address in the href attribute; I
just didn't type the example very well.)
Alan J. Flavell
> On Tue, Mar 4, Chris Morris inscribed on the eternal scroll:
>
> > > the Bobby checker (which I thought was supposed to be based on WAI
> > > guidelines) rejects both ALT="" and ALT=" ", and only declares
> > > itself content when one resorts to ALT=" " or equivalent.
> >
> > It seems quite happy to accept all three equally.
>
> Good news, thanks. When I tried it not so long back, it rejected even
> the precise example which the WAI offer as good practice.
I find I have to correct myself here.
Bobby has no objection to ALT="" outside of links.
However, if it finds ALT="" within the scope of a link, it throws
a priority 1 violation.
If the image had been the only thing in the scope of that link, it
would have been understandable. But, it throws the violation even
when there is text present, and the image was a mere supplementary
decoration. In particular it reports the violation when it is
presented with the WAI's own example of good practice at
http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text-images
I have added my brief comment to the discussion thread at
http://bobby.watchfire.com/bobby/html/en/topic.jsp?thread=268
and sent a more detailed mail to their recommended support address.
best regards
WeSaySo
> Tim wrote:
>
>>> For instance, I have seen browsers *not* show the ALT text, when
>>> you've instructed it to not show images. Which means that pages
>>> where an author has gone to the bother of making images an
>>> optional alternative, but that the images actually formed part of
>>> the structure, the page makes no sense.
>
>
> On Thu, 06 Mar 2003 10:31:44 +0000,
> Stewart Gordon <smjg...@yahoo.com> wrote:
>
>> How about sharing with us the identity of some of these browsers,
>> so we know to avoid them?
>
> Mozilla 1.0 and Netscape 6.2 don't, on Win98SE (here, at least),
> whether or not the image also has a title, or dimensions (though, in
> the case of having dimensions, a "blank" space is left).
Moz 1.1 with images off shows the alt text and the space defined with
width/height. However, it cuts off the text if it overflows the
provided box.
hn
Tim
>>>> For instance, I have seen browsers *not* show the ALT text, when
>>>> you've instructed it to not show images.
Tim <ad...@sheerhell.lan> wrote on Thu 06 Mar 2003 07:45:38p:
>> Mozilla 1.0 and Netscape 6.2 don't, on Win98SE (here, at least),
>> whether or not the image also has a title, or dimensions (though, in
>> the case of having dimensions, a "blank" space is left).
On Sat, 8 Mar 2003 01:58:07 +0000 (UTC),
WeSaySo <tryand...@yahoo.com> wrote:
> Moz 1.1 with images off shows the alt text and the space defined with
> width/height. However, it cuts off the text if it overflows the
> provided box.
Hmm, the older version doesn't. It just didn't show any of the ALT text
(at least, for me) So, I guess they've half fixed a bug, then.
I would think that when I'm browsing in a text mode, I want to read the
contents of the page, and ignore any attempt to use images to format the
page. i.e. Ignore image dimensions, and show the entire ALT text, as
part of the text surrounding it.
Alan J. Flavell
> > Moz 1.1 with images off shows the alt text and the space defined with
> > width/height. However, it cuts off the text if it overflows the
> > provided box.
>
> Hmm, the older version doesn't. It just didn't show any of the ALT text
> (at least, for me) So, I guess they've half fixed a bug, then.
Correspondence with a couple of Mozilla folks in early Jan
centred on this bugzilla item:
http://bugzilla.mozilla.org/show_bug.cgi?id=180620
In response to my comment:
|> So I take it (based on the date of this last bug) that there's
|> something afoot to address this problem?
(I think I'm allowed to quote this much from an email) Hixie replied:
| It's known. I'm not aware of anyone volunteering to fix it.
That still seems to be the situation, since the only change that's
noted since is that another bug report has been opened, and duly
closed as a duplicate.
> I would think that when I'm browsing in a text mode, I want to read the
> contents of the page, and ignore any attempt to use images to format the
> page.
That is very much Hixie's approach, as you might know from
http://www.hixie.ch/specs/alttext
However, the implemented behaviour does not fit the specification, as
Hixie has conceded.
cheers