- From: <Kurt_Mattes@bankone.com>
- Date: Wed, 23 Jun 2004 12:54:34 -0400
- 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 ** 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) ********************************************************************** 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