- 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 ** Kurt, 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 don't. 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]" longdesc="longdescription.html"> 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 above: "When an appropriate markup language exists, use markup rather than images to convey information." JF -- 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