- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 30 Oct 2000 08:35:07 -0500 (EST)
- To: Gregg Vanderheiden <GV@trace.wisc.edu>
- cc: seeman@netvision.net.il, "'WAI (E-mail)'" <w3c-wai-gl@w3.org>
Until there is a mechanism for answering the question "does makup language X work?" I do not support a proposal that relies on having an answer. It just makes the checkpoint effectively meaningless. If we can't answer it in general, or find a way of answering it in general, then we need to be much more specific about what is and isn't acceptable (and in the Techniques document we should explain why - I would rather not have too much in teh Guidelines document itself). Actually, I think the issue is not quite about images per se, although they are the most obvious case. After all, SVG documents are normally images. I think the problem is about having binary encoding mechanisms that produce a fixed presentation. The requirement for accessibility is that the user can control the presentation of information, and fixed presentation formats such as images do not allow that. I am not sure how to express that clearly and succinctly yet <sigh/>. Another example that might illustrate what I am thinking: An audio presentation can be constructed that includes speech, music, some sound effects, and so on. Before television ruled our lives "radio plays" like the Goon Show and Hitchhiker's Guide to the Galaxy commonly did this. I am assuming that the speech content (dialogue, narration) is the basic content for this example. For someone with impaired hearing (and perhaps also with certain conditions that impair concentration and the ability to seperate multiple information streams) the music and effects can interefere with understanding the speech content. Being able to seperate the different tracks using SMIL or a similar technology allows the user to play the speech alone, to get an idea of what it contains, and then to play the full audio to get the "feeling" of the presentation. This doesn't work if all the diffferent parts are encoded into a single binary format (a single wav or mp3 file, for example). end of my example. I also think that given the other checkpoints about providing semantic information, and providing a presentation that is under user control, we have effectively captured the requirements, and this is really a technique. But it is clearly an important technique, and not obvious to everyone. That is why I think it is worth trying to include it as an explicit checkpoint. cheers Charles McCN On Sun, 29 Oct 2000, Gregg Vanderheiden wrote: This looks good to me. Also makes the sentence easier to read and understand. But let's drop the capital letters. I just put those in to show where words had been added. Lisa suggestion then looks like 3.1 When an appropriate markup language exists and will work, use markup rather than images to convey information to allow text scalability. [Priority 2] For example, use SVG for line art, MathML to mark up mathematical equations, and CSS for text-oriented special effects. You may use text in images, when the text has a primarily graphical function, if the effect cannot be achieved with markup, (as in the case of some for logos and limited accent elements) provided that you provide a textual equivalent to the content contained in the image. Adding condition clauses like "when something is true then etc.", always makes automatic testers harder..... but if we don't put them in, then the checkpoints are not practical. Sometimes I wonder if we shouldn't try to work harder on tools to make the pages accessible no matter what they look like........ Having so many legacy browsers makes it almost impossible to design a page which will look right these days. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Human Factors Dept of Ind. Engr. - U of Wis. Director - Trace R & D Center Gv@trace.wisc.edu, http://trace.wisc.edu/ FAX 608/262-8848 For a list of our listserves send "lists" to listproc@trace.wisc.edu -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Lisa Seeman Sent: Sunday, October 29, 2000 1:12 AM To: WAI (E-mail) Subject: Text in buttons - a solution and proposal. (Everybody happy?) OK, I would like to propose a compromise position. Lets change Greg's draft to : "You may use text in images, when the text has a primarily graphical function, if ..." instead of : "You may use text in images when the text does not convey its literal meaning, but has a more graphical function, if". This will address the concern that a designer making a show case site will be restricted. Further if a designer places redundant textual links, then the main function of the graphical link becomes its look. I.E. the primary function is now graphical. However I _can_ not_ make a bitmap of all my BILI text and use that in place text - which was my main concern. Are there any problems with this? The revised proposal is now: 3.1 When an appropriate markup language exists AND WILL WORK, use markup rather than images to convey information TO ALLOW TEXT SCALABILITY. [Priority 2] For example, use SVG for line art, MathML to mark up mathematical equations, and CSS for text-oriented special effects. You may use text in images, when the text has a primarily graphical function, if the effect cannot be achieved with markup, (as in the case of some for logos and limited accent elements) provided that you provide a textual equivalent to the content contained in the image. -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia September - November 2000: W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Monday, 30 October 2000 08:35:16 UTC