- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 25 Feb 1999 16:57:09 -0500 (EST)
- To: Peter Munro <disabled@tdbank.com>
- cc: w3c-wai-gl@w3.org
Bobby is a marvellous tool, being developed by CAST, to highlight accessibility problems in web pages. However, since the bobby team is using the W3C's Web Content Guidelines as their reference, there is a major problem if those guidelines use Bobby as their reference... The Guidelines provide for several approaches. They summarise the underlying principles in a very broad sweep, so that the experienced and the overconfident can simply draw their own conclusions about design. There are 17 Guidelines, which the working group feels ought to be met - each addressing a particular problem. (There is some overlap between guidelines, but that's better than missing a problem) Each guideline specifies a number of checkpoints - tasks which, when done, will provide solutions to different problems (prioritised, according to an external frame of reference). These are all contained within the 'Guidelines document', which is in the process of becoming a fixed reference of some kind. There are two other documents produced by the Page Author Guidelines Working Group: A checklist of checkpoints. These are classified according to various features - for example, all those dealing with form controls, or all those dealing with dynamic interactive content, and further classified according to priority. There is also a techniques document. This explains in considerable detail example solutions for the various problems. This is my understanding of how it works. Charles McCathieNevile On Thu, 25 Feb 1999, Peter Munro wrote: My philosphy is to make a document that can be used as a quick reference and a learning document. Most people will try to fix separate prolems one at a time, before they learn how to fix all problems. Bobby testing software is setup this way. Bobby test software shows all Priority 1 errors in groups. ALT TEXT first and then the next error type next etc. It should be possible to change one type of error at a time by looking at the appropriate section. Here is a segment of what I am talking about. I did not change very much of the existing text. Much of the existing text has run on sentences, and lack definitions. An example of what I am talking about --------------------------- A.1 Provide alternative text for all images, applets, and image maps. Problem: Voice browsers and the visually impaired are unable to read - Images - submit, reset, bullets, - Image Maps - This includes images with one or multiple links. The cursor can not be put over the image. - Program Applets -Applets are unable to be read by early/freeware/shareware voice browsers. This includes images used as submit buttons, bullets in lists, and all of the links within an image map as well as invisible images used to layout a page. Alternative text does not describe the visual appearance of an image, applet, or image map. Rather, it is used to represent the function that the image, applet, or image map performs whether it be decorative, informative, or for purposes of layout. If alternative text is not provided, users who are blind, have low vision, or any user who cannot or has chosen not to view graphics will not know the purpose of the visual components on the page. Since "bare" ASCII art (characters that form images) does not allow alt-text, it must be marked up especially for this purpose Checkpoints: 1.Provide alternative text for all images (e.g., in HTML, via the "alt" attribute of the IMG and INPUT elements, or via "title" or within the content of OBJECT). Note. This includes image used as image maps, spacers, and bullets in lists, graphical buttons and links. [Priority 1] 2.Provide alternative text for all applets and other programmatic objects (e.g., in HTML, via the "alt" attribute or within the content of APPLET, or via the "title" attribute or within the content of OBJECT). (See also A.11) [Priority 1] 3.For all image map links, provide alternative text for each link (e.g., via the "alt" attribute of HTML AREA element). [Priority 1] 4.For all image map links, provide redundant textual links. [Priority 2] if client-side image maps are used, [Priority 1] for server-side. 5.Do not use an image map to create a set of buttons in a form. Instead, use separate buttons or images (accompanied by alternative text). [Priority 2] 6.Replace ASCII art with an image and alternative text. [Priority 1] or [Priority 2] depending on the importance of the information (e.g., an important chart). Note. If the description of (important) ASCII art is long, provide a description in addition to alternative text. (See alsoA.2) Solutions IMAGES The solution is ALT TEXT. This is in the form ALT="Text description". The Alt Text describes the image in words so that the message can be understood without the image. EXAMPLE <IMG SRC="filename.gif" ALT="Text Description " HEIGHT=Y WIDTH=X> < > - Everything within these brackets is the same command IMG SRC="filename.gif" - Put file filename.gif here. ALT="TEXT DESCRIPTION" - Put the text description of the image in the place of TEXT DESCRIPTION. HEIGHT=Y - Y= The Height of the image. Y is an Integer. WIDTH=X - X= The width of the image. X is an Integer ??? Where does the location command go? IE: Align commands? IMAGES WITH LINKS AND IMAGE MAPS The solution is ALT TEXT and text links. Voice browsers must have an ALT TEXT description of the image and text links to follow. The reason for this is the voice browsers can read images, and voice browsers are unable to move over an image to choose a link follow. "PUT SAMPLE CODE HERE" APPLETS Applets allow for the additional of text description inside the applets. Most voice browsers are not able to read this information. ALT TEXT is need by most people and should be included for all Appletts. This is similar to ALT TEXT for IMAGES. What do you mean by bullets etc. The Program BOBBY says that SUBMIT and RESET do nto require ALT TEXT? --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://purl.oclc.org/net/charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Thursday, 25 February 1999 16:57:20 UTC