From the web page http://www.austin.ibm.com/sns/phillj.htm Experiences Implementing Web Accessibility Guidelines in IBM Phill Jenkins IBM Special Needs Systems http://www.ibm.com/sns (800) 426-4832 Bldg 904 IMAD 9448 11400 Burnet Road Austin, TX 78758 pjenkins@us.ibm.com Abstract Experiences implementing IBM's Web Accessibility Guidelines form the basis of this presentation. Also discussed are parts of the "general" accessibility guidelines (including those for Operating Systems and Application Software). The paper describes the way IBM is using the Web internally and externally as an example of what one could be up against in implementing these guidelines at any company or organization. The paper will conclude with some ideas for the future, i.e., tools requirements to facilitate implementation of the guidelines. D Table of Contents * Introduction * Disability Issues * General Guidelines * Web Guidelines * The Journey * Experiences * Appendix Top | Disabilities | General Guidelines | Web Guidelines | The Journey | Experiences | Appendix | Bottom Introduction The World Wide Web has grown phenomenally in recent months to become one of largest components of the Internet and Intranet inside IBM and other enterprises. An important part of this rise in popularity has been the ease with which individuals using software and hardware could access information and resources around the globe. This easy access was made possible by agreement on certain conventions that allowed the server to send out the appropriate documents and the browser program, residing on the user's computer, to interpret them properly. The most common of these conventions is known as the Hyper Text Mark-Up Language (HTML). HTML is very similar to an internal IBM "markup language" that was used to create and maintain millions of legacy IBM documents. The Web's HTML has expanded quickly from the simple document elements such as titles, lists, images and hyper links to more interactive forms, frames, scripting, groupware such as Lotus Notes, and applications written in [JavaTM.]. The HTTP protocol provides a flexible and ever increasingly powerful medium for producing a wide array of different kinds and styles of Web sites. In the beginning, text-only browsers such as Lynx and an internal IBM browser allowed people with disabilities a traditional (text to speech synthesizers) opportunity to access information. The limitations of the internal IBM text-based browser on a VM host 3270 terminal included multimedia operations (graphics, sound, motion video, etc.). The multimedia operations do not map to a 3270 terminal. The movement towards full function PCs with graphical browsers, multi-media elements, as well as the creative freedom enjoyed by authors have created interactive Web sites that rival the real physical world. However, just as the real physical world contains serious access barriers to those who have disabilities, so too can the World Wide Web. Adaptive technology and tools for implementing general accessibility guidelines and the Web accessibility guideliens can now be the key to removing the access barriers. A number of the disability issues can be resolved by carefully designing the Web site. Initially increasing a Web site's accessibility can be an accomplishable task, but as content, browsers, servers and protocols evolve, so too will the task of making Web sites more accessible. It has been a learning experience, based greatly on trial and error, for all involved. Many lessons learned are shared in this paper. Making the Web accessible to all users with varying capabilities will continue to have new and exciting challenges. ToC | Introduction | General Guidelines | Web Guidelines | The Journey | Experiences | Appendix | Bottom Disability Issues It is estimated that there are 600 million individuals worldwide that are blind or who have vision impairments. The U.S. [census] data shows a total of 48.9 million people with disabilities, 24.1 million Americans are severely disabled and 24.8 million have a disability but are not severely disabled. Note: among adults, low vision/blindness accounts for 3.5% and deafness is 2.6%; among children, learning disabilities account for almost 30% and speech problems is another 13%. Accessibility is the set of properties that allow hardware, software, and services to be used by those with a wide range of capabilities. Although typically addressing users who have disabilities, the concept is not limited to disabilities issues. For example users with slow modems who choose to turn graphics off encounter similar issues as those with vision impairments. Solutions for vision impaired users may also help solve access issues for users who may choose to only use a phone type device to surf the Web or access their e-mail. Solutions for adding text captioning for the hearing impaired may aso help provide text indexes for searching video and audio. Issues commonly encountered by users with disabilities are listed here for discussion purposes. There are many sources with more exhaustive definitions, but I have created this summary of six (6) disabilities to quickly increase the awareness of these issues with software and Web site developers. Often overlooked is the seventh (7th) situation where there is a combination of two or more disabilities encountered, or when a proposed solution may create a new barrier for a different disability. * Users who are blind may have difficulty * Obtaining information provided by visual presentation * Using input tools other than a keyboard (mouse) * Understanding a spatial metaphor for navigation * Discerning synthesized speech from other sounds * Users who have low-vision may have difficulty * Preceiving color differences * Preceiving contrast differences * Preceiving depth differneces * Using size coded information * Discriminating fonts * Locating and/or tracking pointers, cursors, drop targets, hot spots, and directly manipulating graphical objects * Users who have hearing impairments may have difficulty * Discriminating frequency changes * Hearing certain frequency ranges * Localizing sounds * Picking up sounds against background noise * Users who are deaf may have difficulty * Sensing auditory information * Producing speech recognizable by voice input * Using English as a second language (sign language being the primary language for people born deaf) * Users who have mobility impairments may have difficulty * Pressing multiple key strokes (poor coordination) * Pressing keys, moving mouse * Moving a limb or reaching * Performing actions that require precise movement or timing * Users who have attention/memory/reading/cognitive impairments may have difficulty * Reading without also hearing the screen read aloud (dyslexia) * Performing actions in cetain time frames * Learning and understanding help information * Discerning function of a graphical object without text label * Users who have a combination of disabilities may * encountered solutions that create new barriers for a different disability ToC | Introduction | Disabilities | Web Guidelines | The Journey | Experiences | Appendix | Bottom General Accessibility Guidelines Various standards organizations and professional associations, such as the Electronics Industries Association (EIA) have published more general guidelines helping product and software designers take into consideration the accessibility issues encountered by users with disabilities. For example, the Electronics Industries Foundation (EIF) has published a Resource Guide for Accessible Design of Consumer Electronics. Inside IBM, We're currently enhancing our general accessibility guidelines to be used by our product and software developers. The Web Accessibility Guidelines are written for content authors and Web site editors, while the General Accessibility Guidelines are written for the browser, authoring tools, and interactive Web developers using scripts and [ JavaTM.] programming. The following general guidelines contain 5 categories with 3 to 4 items listed in each category: * Input * Use system standard input to minimize conflicts with assistive technologies * Enable as many input alternatives as possible * Keyboard enable all tasks, especially navigation * Implement keyboard input guidelines (sticky keys, etc.) * Output * Use system standard output to minimize conflicts with assistive technologies * Enable as many output alternatives as possible (text, & graphic, & sound) * Implement display output guidelines (show sounds, user selectable fonts, etc.) * User Configurations * Enable switching between input / output without reconfiguring, restarting, or rebooting * Enable user profiles to be created, saved, and modified * Timing ranges should be user adjustable including OFF * Enable users to customize pointing devices (left or right hand mouse, etc) * Object / Window appearance, behavior, and focus * Provide meaningful object labels and descriptions accessible as text * Indicate via multiple ways which object/window is currently receiving input focus * Don't confuse navigation with selection or activation * Return input focus to where it was last time the object/window had focus * Errors and User Notifications * Notify user in consistent manner when "new" information is presented * Allow information to persist until user dismisses it * Enable "undo" of unintended actions * Provide descriptive text for information presented in video or audio ToC | Introduction | Disabilities | General Guidelines | The Journey | Experiences | Appendix | Bottom Web Accessibility Guidelines Many of the following Web accessibility guidelines are used in publishing the IBM Special Needs Web site, they should be a resource for you in making your site more accessible to those with disabilities. * Use ALT="TEXT" attribute on all image tags * 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 without being to wordy so that it interferes with efficient browsing. * Provide a description of significant graphics (the "D" link). * Provide text transcription / descriptions for audio and video clips * And, test the page with text-only browser and graphics turned off. ToC | Introduction | Disabilities | General Guidelines | Web Guidelines | Experiences | Appendix | Bottom Beginning the Journey IBM Special Needs Systems started the journey of making a presence on the World Wide Web in 1995 and making our Web site more accessible in the fall of 1996. Since 1914, IBM has seen technology as a way to enhance the employability, education, and quality of life of people who have disabilities. For over 10 years, IBM Special Needs Systems, under the Independence Series trademark , has developed a number of assistive devices, software tools, and guidelines that make the computer more accessible and useful to people who have vision, hearing, speech, mobility, and attention/memory disabilities. The inital purpose of the our Web site was to market IBM and business partner solutions and to assist in bringing together teachers, vocational rehabilitation professionals, various associations, advocacy groups, governments, the social, academic, and medical communities, and people who have disabilities -- to work together to develope and use technology to open doors for achievement and independence. A secondary purpose of our Web site was to experiment in developing and showcasing the accessibility guidelines. An initial goal for the Web site was to prove that a visually appealing site with a professional marketing presence could also be very accessible. Using the IBM OS/2 Warp operating system platform and RISC/6000 servers, the journey of hand writing and testing accessible HTML began using the OS/2 WebExplorer browser and ScreenReader/2. Every effort was made NOT to divide the site into two parallel streams, one being text-only, and the other more image intensive. Browser and server tools requirements needed to be identified so that a single site could be easily maintained. A more text-based rendition would be beneficial to persons with vision impairments and to those people with learning disabilities that use text-to-speech screen reader programs, while the image intensive rendition of the site would assist users who are extremely visually oriented in the way they process information as well as users using mouse alternatives who may appreciate larger selection targets. ToC | Introduction | Disabilities | General Guidelines | Web Guidelines | The Journey | Appendix | Bottom Experiences Implementing the Guidelines The Web Explorer and Screen Reader/2 combination employed features that proved to be key in designing and maintaining a single accessible site. Text-based browsers and GUI browsers like Netscape Navigator and Microsoft Internet Explorer were also used. Also a browser compatability and accessibility assessment tool named [Bobby] was used. The observations and potential requirements are discussed. An initial observation was the differences in browsers handling formatting with graphics turned off. The Web Explorer placed the alt=text in line with the rest of the text without any additional boxes or icons being used to show where the image would have been loaded. It generally ignored the align tag and presented the information more like a "text only" browser. Except for the case when no alt=text tag information was provided, which resulted in "nothing" being presented, this technique proved more friendly with screen readers. Adding a special character, as opposed to a larger icon image, would be helpful in identifying images without alt=text tags. Another alternative would be for browsers to implement new .jpg (and oneday .gif) standards to "automatically" include a text label, perhaps the filename, if the graphic author did not provide a descriptive tag. When browsers format the information as if images are being loaded by placing the alt=text in the "middle" of the image space, many times the screen reader user misunderstands the information because of multi-column and muti-line formatting. This browser behavior may continue to encourage screen reader users to use text-only browsers that may not be generally supported by the organizations IT group. Minimum standards may need to be established and enhanced so that "images-off" is equivalent to "text-only" behavior. Many screen readers as well as sighted users have a hard time identifying links. Although most browsers support the "underline links" user preference, many content authors include "image text" to insure the desired font is displayed or the browser draws a line under otherwise normal text. With the continued use of mouse navigation alternatives such as voice navigation, browsers are supplying a list of links for the user to navigate and select. Some browsers also provide an indented list of visited URLs creating a map of all the paths taken during a session. The popularity of using the simpler devices such as phones and "TV set-top boxes", may prove to have a positive effect ensuring keyboard navigation and selection. IBM Unique Experiences Applicable to Other Organizations Many internal IBMers were still using non-graphical systems that had text-only browsers. Much of the legacy information content was also stored in a text based format. Both of these situations insured for a while that the internal content authors and editors were sensitive to the same requirements as disabled users. As also observed in the general public, more of the users were migrating quickly to graphical user interface (GUI) based browsers and providing content tailored to the GUI, ignoring the old requirements. The challenge is to provide tools that implement the accessibility guidelines as fast as the new technology encourages the content authors to exploit the new technology. In addition to tools, education and simple awareness needs to continue and be accelerated. Inside IBM I approached it in two ways, both top-down and bottom-up. The very open nature of the Web encouraged roll your own development, so the actual authors needed to be aware of the disability issues. Guidelines were placed whereever sites had collected tips, tools, and other resources hoping to catch the new author. Guidelines were also target at existing site editors. IBM is a very large company consisting of hardware, software, services and internal operations. There were over 600 internal Web sites with 1.5 million hits a week to the "Think Online" page. The software group, for example, is comprised of divisions which are comprised of organizations, which are comprised of departments and teams. Each potentially having it's own Web site and site editor at each level and NOT having any actual hierarchical relationship in it's on-line Web sites. Managing the ibm.com domain addresses is a difficult task in and of itself. Centrally managing all of the Web sites would be an impossible task not to mention the posibility of destroying the very nature of the Web itself. The bottom-up approach of getting the guidelines to existing site editors is an on-going task. The next approach will be more top-down, actually educating key management responsible for the various Web sites. The difficulty here lies in understanding the relationship of external "Web sites" to the internal "company organization". The internal organization seems to map readily to internal Intranet sites. The external Web sites do not always map to the company organization. However, the external Web sites have a more understandable structure which maps back to the main IBM home page. This top-down hierarchy and navigation structure not only ensures the usefuleness of the Web sites, but thankfully, assists in adopting the accessibility guidelines. The World Wide Consortium's (W3C) Web Accessibility Initiative (WAI) has all the elements necessary to successfully influence the current issues and future challenges. Hopefully information in this paper will continue to help IBM and other organizations to use technology to open doors for achievement and independence of individuals and enterprises. ToC | Introduction | Disabilities | General Guidelines | Web Guidelines | The Journey | Experiences | Bottom Appendix * Keyboard Input Guidelines * Display Output Guidelines * Use ALT=TEXT tag on all images * References and Links Keyboard Input Guidelines The following 11 more detailed keyboard input guidelines are listed for software developers: * Enable multiple key combinations to be entered sequentially or mapped to single key. Example: Sticky Keys * Enable the onset of key repeat to be delayed. Example: Repeat Keys * Enable a delay between keystrokes before acceptance. Example: Slow Keys * Enable a key to be held down for a set period before acceptance. Example: Bounce Keys * Enable alternate serial input to control the keyboard (GIDEI standard). Example: Serial Keys * Enable keyboard control of pointer movement and button functions. Example: Mouse Keys * Enable visual & auditory indication of status of control keys such as "CAPS Lock" or "Num Lock". Example: Toggle keys * Provide key(s) to accelerate frequently used features. Example: Accelerator Key Ctrl-P to print * Avoid key mapping conflicts. Example: Shift key held down greater than x seconds turns On/Off SlowKeys & RepeatKeys * Avoid key sequence conflicts. Example: Ctrl key held down (and not released) for Ctrl-P is not confused by system with other Ctrl toggles * Enable re-mapping of accelerator and function keys. Example: A user with only a left arm may wish to re-map keys * Separate Navigation keys from activation keys. Example: Tab key to move, while Space bar activates ToC | Return to General Guidelines Display Output Guidelines The following 8 more detailed display output guidelines are listed for software developers: * Enable user to select among font sizes, styles, and colors. Example: Systems font selections * Enable user to change attributes of graphics. Example: line, border, and shadow thickness * Don't use text to draw lines, boxes, or other graphical symbols. Example: some Screen Readers read characters sequentially * Provide high contrast monochrome palettes. Example: aid low-vision & avoid confusing users who have color blindness * Enable user to select background & foreground colors. * Enable customization of colors used to indicate selection, process, or status. * Indicate selection, process, or status with both visual & audio * Enable alerting users of events via display "flashes" other than audio beeps. Example: Show Sounds ToC | Return to General Guidelines Use ALT=TEXT attribute on all images attribute should also be added to the tag. This allows text to be displayed in place of the image if the user has images turned off on the browser or, more importantly, is running a browser that doesn't support images. All tags in a HTML document should have the attribute. Example: go back The hyperlinked text can be highlighted appropriately by the content author or forced by the user preferences. The following conventions are being proposed: Conventions: * text should be a descriptive phase * use TITLE= attribute on the nchor tag to describe the destination of image links * consecutive hyperlinks should be separated (by NON-linked text such as "|") * text should only be inclosed in [brackets] if it is necessary 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. * alt=text including brackets for in-line graphics such as [logos] or [icons] would be more appropriate especially for non-hyperlinked text * Occasionally "text images" are used for highlighting or for special fonts. Cascading Style Sheets solves many of the reasons to do "text images" for special fonts. When images are used, the ALT="text" can regularly be just the text from the image with no additional special characters or brackets. . For example: * "The product has been !" alt=[updated]! would be less noisy if the ALT="updated" attribute had no brackets and would be rendered like this: * "The product has been updated! Efforts are underway for authoring tools and standard image file formats to include the "text" tag automatically as part of the image file so that it is not a manual exercise to add the text description. 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 look more like text-only browsers when images are turned off. Plain Background 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, then alternate ways of presenting the information should be considered. ToC | Return to Web Guidelines References Adobe Adobe Acrobat Access: Now the blind can access PDF (Acrobat) documents free from Adobe. http://www.adobe.com/acrobat/access.html . Bobby CAST, Center for Applied Special Technology. BOBBY. http://www.cast.org/bobby . Census Data J.M. McNeil, Americans with Disabilities 1991 - 1992, Bureau of Census Population Report, 1993 Government References Public Service Commission of Canada. Webpage Accessibility Self-Test: http://www.psc-cfp.gc.ca/dmd/access/welcome1.htm . U.S. Governments Services Administration (GSA). Writing Accessible HTML Documents. http://www.gsa.gov/coca/WWWcode.htm . IBM References IBM Special Needs Systems Home Page. http://www.ibm.com/sns . IBM JavaTM Home Page. http://www.ibm.com/java . IBM alphaworks Home Page. http://www.alphaworks.ibm.com/ . JavaTM JavaSoft Home Page. http://www.javasoft.com/ . Starling Chuck Letourneau. Starling: Accessible Web Page Design http://www.starlingweb.com/acc/actoc.htm . TRACE TRACE Research and Design, Design of HTML Pages to Increase Their Accessibility to Users With Disabilities. http://www.trace.wisc.edu/HTMLgide/htmlgide.htm . W3C World Wide Consortium's (W3C) Web Accessibility Initiative (WAI). http://www.w3.org/WAI/ . Related Topics from the 6th International World Wide Web Conference Browsers and Tools Critique and Analysis of Web Applications Design principles and techniques Programmatic and Specialized User Interfaces Universal Design ---------- End of Document