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

RE: alt text & punctuation - best practice?

From: <Kurt_Mattes@bankone.com>
Date: Wed, 23 Jun 2004 12:54:34 -0400
Message-ID: <B239BEDED044074C8E2CCC3A9162F2A90A26D895@swilnts804.wil.fusa.com>
To: <foliot@wats.ca>, <poehlman1@comcast.net>, <sdale@stevendale.com>, <david@djwhome.demon.co.uk>
Cc: <w3c-wai-ig@w3.org>

Thank you, thank you, thank you.  Still working on a "way", 
so I can honestly say I don't have one yet, but do have multiple 
stakeholders to satisfy.  The "way" I am trying to find is one 
that does the best job of satisfying as many seemingly 
conflicting needs as possible.  This may become a futile effort, 
but I am not done trying yet.  A complete redesign of several of 
the sites I oversee is in the works for next year, so 
opportunities to change existing design habits exist.

It is very confusing and frustrating when I look at the W3C site 
and see images with text in use, but read on this list that they 
should not be used.  Two examples I can think of where an image is 
required [by banking regulations in the US] are an FDIC insured logo 
and an equal opportunity lender logo.

Last week while reading some other material I discovered the
http://www.csszengarden.com/ site and was amazed.  Since then
I have been working on proof of concept pages to incorporate
several of the CSS ideas into our new design.

Sorry if I left the impression that I was trying to treat the
symptoms without addressing the real problems.  There are
thousands of pages and images on these sites, designed by 
teams of designers, with content and design issues influenced
by multiple business owners.  And then there are partners, like
Disney, Amazon and United Airlines that provide content and 
images for use on their branded versions.  Telling all that 
images may not be used would be suicide and lead to few if any
accessibility improvements.  At some point compromises will be found.  
The information you have kindly provided will assist with finding and 
prioritizing them.

Again, I cannot thank you enough!

Kurt Mattes
Application Development Analyst
Technical Lead - Web Accessibility
[302] 282-1414 * Kurt_Mattes@BankOne.com

-----Original Message-----
From: John Foliot - WATS.ca [mailto:foliot@wats.ca]
Sent: Wednesday, June 23, 2004 11:18 AM
To: Mattes, Kurt (Bank One); poehlman1@comcast.net;
sdale@stevendale.com; david@djwhome.demon.co.uk
Cc: w3c-wai-ig@w3.org
Subject: RE: alt text & punctuation - best practice?

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

This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
Received on Wednesday, 23 June 2004 12:55:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:28 UTC