W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2004

RE: alt text & punctuation - best practice?

From: John Foliot - WATS.ca <foliot@wats.ca>
Date: Wed, 23 Jun 2004 11:17:57 -0400
To: <Kurt_Mattes@bankone.com>, <poehlman1@comcast.net>, <sdale@stevendale.com>, <david@djwhome.demon.co.uk>
Cc: <w3c-wai-ig@w3.org>

> That goes a long way to clear up the issue.  Assistance like this
> IS detrimental to the cause.
> Kurt Mattes
> Application Development Analyst

** With due respect **


The problem is, you keep arguing for continuing to do things your way, but
you want to make it accessible.  Older voices on this list keep telling you
that the accessible way is to do it differently.  What David is saying is
put the text on the page.  Can you give an example of how/why this would not
be an optimum solution?

The W3C's WCAG states:

	Priority 2 - 3.1 "When an appropriate markup language exists, use markup
rather than images to convey information."

It can't be clearer than that.  You keep asking how, many keep suggesting

To further answer your question requires a "it depends" answer... it depends
on the instance.

	1) suppose you are displaying an icon on your page which contains text.
You could simply echo the text in the image, but is that enough?  Perhaps
something like this would be more appropriate: <img src="" alt="[icon -
download the foobar today]">.  However, if it is a button, perhaps alt="FAQ"
is enough, adding info that it's a button is superfluous (alt="[button -
FAQ]" is not desirable).

	2) you've added a decorative flourish which contributes nothing to the
information on the page? alt="" is enough

	3) you've added a pie chart of information to the page.  This one is
tricky, because the alt text *should* indicate that the image is a pie
chart, but then what of the content "inside" the chart?  longdesc would be
one solution, but a text based alternative within the body of the document
is probably preferable.

		a) <img src="" alt="[pie chart - user base for the different browsers]"
		b) <img src="" alt="[pie chart - user base for the different browsers]">
			<table summary="user base for the different browsers"> data here </table>

(You will also note that I bookend my alt text with square brackets... this
is not on any guideline or best practices anywhere except internally in my
shop.  I add them so that text only browsers can more clearly differentiate
between the text in an alt tag and basic text.  Given that the majority of
screen reading technologies can adjust their verbosity and grammar settings,
it generally is a non-issue, and IMHO adds but does not detract.)

	4) you've got an image which advertises a new service or product.  DON'T.
It's simple... it will not be accessible to all, it can't be as it relies on
a visual rendering to convey the intent.  Perhaps instead create a div or
other container, style it up with CSS to your heart's content, but embed the
subject text as text, again styled as you wish through CSS.  If you really
must use imagery, perhaps look at SVG (scalable vector graphics) as an
option, but note that it is still in the experimental stage and far from
mainstream (http://www.w3.org/Graphics/SVG/).  With apologies to Macromedia,
Flash is still not a totally accessible option, although Macromedia are
working hard to improve that situation.

Kurt, no one on this list will argue that accessible sites need be ugly or
boring... far from it.  Many of the old hands attempt to push the boundaries
to show what is possible with standards compliant, accessible web
development which still has an aesthetic to it.  If you have not already
visited the CSS Zen Garden run, don't walk (http://www.csszengarden.com/).

In re-reading your post, I get a sense that you are attempting to apply
band-aids and patches to your content to salvage what you have.  This
unfortunately may not be the ultimate answer.  What matter if some
magnifiers enlarge "tool tips" and others don't?  Are you going to state
"Best enlarged with *foo* magnifier" somewhere on your site?  Is that
magnifier available for all operating systems (PC, Mac, Linux/Unix, etc.)?

Why are you even relying on "tool tips", when their behaviour/appearance is
sporadic at best, invoked differently on different browsers, etc. (to render
them in the Mozilla class browsers requires the use of the title attribute)?
The fact that "tool tips" show up should be considered a bonus or
enhancement, but should not be relied upon for anything "Mission Critical".
Sure, install one if you want to experience the experience, but there are a
number of different solutions out there... are you going to install each and
every one of them, on each and every possible OS configuration, so that you
can test your site?  At what point do you draw the line?

No, developing to Standards and Guidelines is the only real way of achieving
any kind of consistency.  As other threads currently unfolding emphasize,
the Adaptive Technology still has a role and responsibility to play as well,
but we are not AT developers, we are web developers.  The defacto standard
for accessible web development is still the W3C WCAG (flawed that it is),
and so, at the end, all we can really do is go back to the guideline quoted

	"When an appropriate markup language exists, use markup rather than images
to convey information."

John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)
Received on Wednesday, 23 June 2004 11:18:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:33 UTC