Web Accessibility Guidelines (http://www.austin.ibm.com/sns/access.html) The following guidelines come from the basic principle that information should be seperate from the presentation medium. The information in the Web site should be "marked up in HTML" so that the information can be viewed spoken, printed, or brailled. * Use ALT="TEXT" attribute on all images * Use Cascading Style Sheets (CSS) * Provide an alternate list of links for image maps * Avoid use of tables or provide alternative * Link text should be descriptive (more than "click here", or "this") * Provide a description of significant graphics (the "D" link) * Provide text transcripts & descriptions for audio and video clips * And, test the page with a text-only browser and graphics turned off. As the Web evolves, these guidelines will evolve to reflect new accessibility issues. Several Web sites have already been designed following these and other guidelines. Please refer back to these guideliens here or to the IBM Special Needs home page in the future. If you are responsible for Web page design, we hope that you will follow these guidelines when designing your site. From Phill Jenkins , IBM Special Needs Systems Where Access has been our business for over 10 years. The guidelines are used in publishing these IBM Special Needs web pages, they should be a resource for you. Phill Jenkins Software Engineer IBM Special Needs Systems Bldg 904 Zip 9448 4G-020 11400 Burnet Road Austin, TX 78758 (512) 838-4517 IBM tieline 678-4517 pjenkins@us.ibm.com ----------------------------------------------------------------- IBM Special Needs Systems snsinfo@us.ibm.com (Internal IBM SNS intranet web site) Home Page: http://www.ibm.com/sns (800) 426-4832 (c) Copyright IBM Corporation, 1997 ---------- Use ALT="TEXT" attribute on all Images attribute should be added to ALL tags. This allows text information about the image to be retreived by the user if the user has images turned off on the browser, is running a browser that doesn't support images, for example a phone or audio-only browser, or, more importantly, the user is vision-impaired and can only get the imformation about the image from its ALT="TEXT" attribute. Example: go back Conventions: The following conventions are being proposed. The general idea is to construct the ALT=TEXT so that the resulting Web document renders all the information as if the author had no IMAGEs. * Text should be a descriptive phase * Text should not be a description of where the link is going to * Consecutive hyperlinks should be separated by NON-linked text such as "|" * Text should only be enclosed in [brackets] to separate it from the rest of the surrounding text * Unnecessary use of [brackets] adds to the clutter & noisiness * "[top] | [bottom]" navigational bar could more simply be shown as "top | bottom" with no brackets. * text enclosed in [brakets] for in-line images such as [logos] or [icons] would be more appropriate especially for non-hyperlinked images * Occasionally, "text images" are used for highlighting or for special fonts. The ALT="text" then could be just the text in the image with no additional special characters. For example: * "The product has been !" would have the ALT="updated" tag with no brackets and be rendered like this: * "The product has been updated! Some authoring tools and HTML editors prompt for the automatic insertion of the ALT=TEXT attribute. Browsers today offer the option to the user to display either the images or alternatively the "text" description. Browsers format the page differently from each other when graphics are turned off. Some browsers place the text in the space the image would have taken, others reformat the text and leave no space for the missing image. Background Images A site should be designed with mostly plain backgrounds because complicated background patterns can make it difficult for persons with low vision to read the foreground information. If the background has information in it, for example light text messages or color coding, then alternate ways of presenting the information should be considered. ---------- Use Cascading Style Sheets (CSS) Cascading Style Sheets describe how documents are presented on screens, in print, or perhaps how they are pronounced or brailled. Style Sheets is a elegantly designed yet simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents. By attaching style sheets to structured (e.g. HTML) documents on the Web, authors and users can influence the presentation of documents without sacrificing device-independence or adding new HTML tags. CSS is one of the greatest hopes for separation of presentation from content. The Web is the ultimate cross-platform system, and your content will be presented on such a huge variety of devices that source pages should specify the meaning of the information and leave presentation details to a merger (or "cascade") of site-specified style sheets and user's preferences. If the introduction of WebTV or "accessibility" or audio browsers broke your pages, you will appreciate the ability to introduce new page designs by creating a single style sheet file rather than by modifying thousands of content pages. Style sheets have been an activity since the World Wide Web Consortium (W3C) was founded and have resulted in the development of CSS1. For background and tutorial information on style sheets, see the Web style sheets resource page. Aural browsers as well as screen readers, will be able to take advantage of the standard styles when presentting Web information to persons who have disabilities. ---------- Provide an Alternate List of Links for Image Maps Provide a list of text links when using an image map. The list of text links would be phrases representing the clickable regions on the image. For Example: If you had an image of a world map, where each country boundry region was a hyperlink, you would also need to list each of the countries as hypertext links. Austria | Australia | etc. Belgium | Belieze | etc. USA | etc. ---------- Avoid Use of Tables or Provide an Alternative Screen Readers read the screen much the same way sighted users do; from left to right, top to bottom, one line at a time. The problem occurs when the text is formatted into tables or multiple columns. Since there is little syntactic information about the table available to screen readers, it is left to guess about boundaries of the columns or table's cell borders. Example: This is This is This is the 1st the second the 3rd column column column The screen reader would read one line across all three columns; line one from column one, then line one from column two, and then line one from column three all together. Aurally, the blind user would hear from the voice sythesizer the following: "This is, This is, This is" And then user would hear the second line from column one, the second line from column two, and the second line from column three. For example, "the 1st, the second, the 3rd". And so forth. This problem could be avoided by simply creating a list with 3 items in it, instead of the 3 column example above. Some basic rules would include the following: * Use CSS for positioning and formatting, do not use tables. * Don't use a table when it can be avoided. Most simple tables that do not have multiple row or column headings can be represented as a simple list. The table formatting would not add any value or simplify the presentation. * Do use tables for true tabular information (i.e., mileage chart). * Do use relative formating so that the table will take up all the space available in full screen mode. This will allow enough space so that text in each table cell will not need to wrap to a second line; avoiding the problem in the example above. * Do provide a text-only page interpreting complex tables. Screen Reader vendors are developing ways to recognize white space and rules around tabular information. New table attributes are also being proposed that will implicitly identify the cell's heading and row identifier so that it is not left to the visual presentation to determine that information. ---------- Link Text Should Be Descriptive Link text should be descriptive (more than "click" or "here") without being too wordy so that it interferes with efficient browsing. Several browsers for voice navigation, as well as screen readers, now list the links separately. When the link is read in the list, out of context, can it be understood? That's the simple test. ---------- Provide a Description of Significant Images The information contained in the image needs to be available in a form other than the image itself. The "description" is longer and more significant than the ALT=TEXT caption. A simple approach is to provide a separate text description of the following types of images: * Icons, logos, trademarks, and brand images * Potraits, landscapes, shapes, and objects * Collages, abstracts, and art It is not necessary to describe bullets, headrules, backgrounds, etc. unless the author feels it is important to capture that information and provide it to the user. Example: D The CPB/WGBH National Center for Accessible Media (NCAM) announced the availability of the Web Access Symbol for use! This image may be used by Web authors to denote that their site contains accessibility features to accommodate the needs of disabled users. There is no charge to use this symbol, and it may be used in electronic or printed form. The symbol should always be accompanied by its description: A globe, marked with a grid, tilts at an angle. A keyhole is cut into its surface. The description can be on the same page, on a separate page, or on a page with a listing of the descriptions of all significant images on that site. The current convention is to hyper link the description from the capital letter "D" following the image itself. And, of course, the ALT="[Web Access Symbol (for people with disabilities)]" attribute is always included on the IMAGE tag. ---------- Provide a Transcript & Description of Audio and Video Clips The information contained in the clip needs to be available in a form other than the clip itself. The transcript is a word-for-word script of the audio. The user has the choice of reading the transcript or listening to the clip. The "description" is longer and more significant than the "transcript". The "audio description" would need to be available in text form. The video description should be available in both text and audio form. The description can be both subjective and artistc, depending on the intentions of the author. This information is generally available at the beginning of the creation process and should be retained and made available on the Web along with the clip. It may not be necessary to describe "earcons" or "soundcons" (audio clips) that are associated with bullets, headrules, backgrounds, etc. unless the author feels it is important to capture that information and provide it to the user. Example: See the CPB/WGBH National Center for Accessible Media (NCAM) Web site for examples. The descriptions and transcripts can be on the same page, on a separate page, or on a page with a listing of the descriptions of all significant clips on that site. The current convention is to hyper link the transcript & description from near the clip itself. ---------- Test the Web Site for Accessibility Test the site with a variety of browsers: * text-only browser * grapical browser with graphics turned off * audio browser * print * braille The intent is to insure that the information the author wants to communicate is available in various mediums. Testing your page with a variety of users and environments will also help insure that your page is accessible. Example: Check the accessibility of your web site with CAST's web HTML analyzer, Bobby, Version 2.0 Bobby is an easy to use program that will help identify those areas of your page that do not follow the accessibility guidelines. BOBBY will also find HTML compatibility problems that prevent pages from displaying correctly on different web browsers. ---------- End of Document