Page PageSusan M. Johns, Axe Library
Pittsburg State University
25 March 2002
Many web sites offer accessibility checkers for ascertaining the compliance of various web pages with Section 508 ADA compliance. Bear in mind that there is *no* one single product or site which can validate, fix, or retrofit your site for compliance. Certain commercial products, (such as http://www.accessibilitymonitor.com/) can, for a substantial cost, retrofit pages to certain compliance standards, but still require human input and some redesign for maximum accessibility. As most pages at PSU are coded locally by faculty and students, it is perhaps more feasible for authors and coders to examine several sites and understand underlying principles *prior* to design to maximize effectiveness.
State of Kansas mandate for March 2002 indicates that all pages should be HTML 4.0, XHTML 1.0 and CSS Level 2 compliant. Further information can be found at http://www.da.ks.gov/itec/WASPriorities112001.htm and at http://www.da.ks.gov/itec/ITPoliciesMain.htm. The summation of the task at hand is to make pages compatible with a variety of disabilities: vision, hearing, and motor skill capabilities, at the very minimum.
Approaches to accessibility should include at minimum the evaluation of a web page or web site from various aspects: browser dependence; specific vendor product functionality; screen/voice readers; screen magnifiers; color dependence; code validators; motor skill and navigational flow; sound cues; and cognitive design for specific user populations.
ADA accessibility is *not* just designing for THE blind. You are coding for the blind, the low-vision user, the color-blind user. You are coding for the hearing impaired, the motor-skill impaired, and specific population cognitive understanding. You are designing web pages for people with bifocals, people with carpel tunnel syndrome, and people with Parkinson's disease. It is important, then, that the design of the web page is sensitive to color, magnification, and text versus graphical renderings, as well as cognitive and motor-skill issues.
Web pages should be tested against multiple browsers. Netscape, both current and earlier versions, tends to be the loser in this evaluation because of its lack of support for cascading style sheets (CSS, Level 1 and CSS, Level 2). One cannot presume that the user, particularly the distance user, will always use the browser you had in mind when designing the web page. Much literature exists on the trend "any browser should work" debate, that is, the html code should execute correctly in any browser, and if it doesn't, "too bad for that browser". In effect, by supporting code standards, it is hoped that the browser companies will be forced to catch up and provide a project capable of adherence to federal ADA standards.
Web pages may look different from browser to browser. It is therefore critical to understand what is important on your page and what is not. The goal is not to create a page that renders *exactly* the same from one browser to the next, but to create a page that renders *coherently* from one browser to the next. Know when to let go of subtle differences, particularly when they do not affect the accessibility of the page.
Minimally, web pages should be tested against Amaya (http://www.w3.org/Amaya); Internet Explorer (http://www.microsoft.com/); Opera (http://www.opera.com); Lynx (http://lynx.browser.org); and Netscape (http://netscape.aol.com/) (note: addresses updated October 2007). Do not minimize the use of Lynx -- it is a useful tool in identifying major graphical problems, and is heavily used by the blind community because of its ease of use with various screen readers. Backwards compatibility with older browser versions should also be tested, although success will be limited due to poor style sheet functionality in the earlier browser releases.
The true test of real accessibility is ultimately awarded by users who need it most. If your enabled user population has a clear preference for vendor products specific to their disability, test with those products. (For instance, State of Kansas SRS tends to award monies to their clients for purchase of JAWS for Windows. JAWS is not a de-facto national standard, but clearly if a significant portion of the user population has JAWS loaded on their computers, testing with JAWS will meet the needs of a significant number of users.)
Specific screen, magnification, and color tools in use by coders and users alike, include the following:
JAWS for Windows:
Significantly expensive because of the Braille interface, demo copies are available for download. JAWS is a significant player for the absolute blind because of the Braille interface, and is used heavily by low-vision users because of robust voice and navigation functionality. JAWS is not a standard, but predominates in terms of the number of users. Its screen reading capabilities are a good start to evaluate your page both for the screen reading and for the motor-skill design issues (addressed later) in terms of navigation for physical impairment.
Zoomtext: http://www.aisquared.com/
Zoomtext is a magnifier with a screen reader, designed primarily for low-vision users. Zoomtext is useful in identifying fixed-pitch fonts, and understanding the relationship of dynamic sizing in terms of proportion and percentages. It is critical that text and graphics maintain a sense of proportion when using a magnifier. Zoomtext also is useful in identifying poor quality logos and graphics which literally disappear at as little as 4x magnification. Zoomtext is also useful in identifying poor quality fonts, such as italics, and illustrating their complete illegibility at higher magnification levels. Zoomtext can also identify disappearance of font color on larger scale magnification depending on shade and style.
Vischeck: http://www.vischeck.com
Vischeck simulates colorblindness, three types, but is primarily useful for deuteranope (red/green) colorblindness. Vischeck illuminates lack of contrast with text, graphics, and navigation, and is an eye opener if you rely heavily on color cues to differentiate information, links, buttons, and navigational paths.
Validators refer specifically to sites which validate the HTML, XHTML, or XML code. They do not validate the accessibility except by inference, that is, the more closely the web page follows coding standards for HTML 4.0, XHTML 1.0, CSS1, or CSS2, etc., the more likely the web page will provide clean coded-pages which render them more consistent and navigable for accessibility.
The most comprehensive validator is the W3C Validator, http://validator.w3.org. CSS, HTML, XHTML, and XML validation is provided here, as well as the various iterations of strict vs. transitional code variances. It is by far the most comprehensive validator site available. If you have not used the site previously, it will be slow going initially until you familiarize yourself with its syntax and absolute attention to detail (something as simple as a misplaced <p> tag can cascade the remainder of the page into an abyss of gobbledygook), so do not get discouraged with the voluminous error messages. Pages do validate, and you earn your keep and feel great when they do.
Bobby: http://webxact.watchfire.com/
Bobby is not actually a validator of code but rather an analyzer of style elements. Bobby will give you coding validations to a point, but it is worth remembering that even if your site is "Bobby-Approved", the site may still be non-compliant; and conversely, just because your site may not receive the Bobby thumbs-up, does not necessarily mean the site is *not* ADA-accessible. Bobby is a good starting point to begin to understand design elements and their priorities, but simply having Bobby approval does not insure that the web page meets full compliance (urls updated 2007).
Other checksites can be found at http://wave.webaim.org/index.jsp, or listed at http://library.pittstate.edu/staff/susan/adavalidate.html
Motor-Skill accessibility allows you to successfully navigate through a web page without a mouse; without a keyboard; or in extreme cases, with a focus light or mouth stick. A simple way of seeing what a navigation path on a web page (this includes user-submitted forms) is to <tab> through your page, and then try to <back-tab> to the top. Where does your cursor go? What links, graphics, sites, or text can you not access?
If the page has forms input, pull down combo boxes, edit boxes, etc., can you traverse the links, pull down the data, type in search terms in the edit boxes and launch the search with the use of the tab and <enter> keys? Can you fill out a form and submit the form from the keyboard without having to pick up the mouse and "see" the <GO> button or click on the <submit> button as part of the <tab> sequence through the page?
Motor-skill also include how you navigate, or move around the page. Not all sites necessarily need a full table of contents, but how do you skip from paragraph to paragraph, or heading to heading *without* using the scroll bar? Is the page summarized in a small menu or table of contents? Can you immediately go to the bottom? Can you immediately come back up to the top? Can you retain the continuity of adjoining web pages on the site without having to leave the page and use the browser <back> or <forward> buttons? Can you *skip-over* sections if the choices are multiple and repetitive page after page after page so that a user can immediately go to the content rather than wade through 43 links of where else they might want to visit rather than read the content of a specific page?
ADA specifications for motor-skill accessibility are probably the *most* critical design issue behind being able to "read" the page with a reader or magnifier, because the disability affects all of us: carpal tunnel syndrome, workers with temporary wrist/hand/elbow/finger injuries, those with arthritis, etc. Motor-skill accessibility also lends itself to support of multiple interface devices, including the use of palm-pilots, PDAs, cellphones, and other high-end tech devices to navigate the interface. Whether the web page is traversed by a PDA stylus or a mouth stick of a severely paralyzed user, the result should be the same: clear, and useable navigation of the site with a single keystroke.
Various sample sites (good and bad) that can be used as examples for skip links, navigation techniques, menus, hidden menus known only to the screen readers, forms input, and PDA format styles can be found at http://library.pittstate.edu/staff/susan/adapda.html.
Cognitive Accessibility relates to a wide variety of content and thinking processes, and includes the ability of the site to be used with unique and specific population abilities. These can include, but are not limited to young children, seniors, non-English speakers, and international users. Cognitive accessibility is not dumbing down the site to words and pictures, but allowing the site to be used simultaneously by users with a unique, intuitive perspective.
Are there abbreviations, slang, or terminology which, while familiar to you, might be completely nonsensical to someone from another country? These include defining abbreviations, spelling out acronyms, and being familiar with cultural and language subtleties.
Can you keep a child or young adult's attention? Can a page, or section of the page, be re-read a second or third time without requiring a senior to retrace their steps and *start over* rather than going back to review a key paragraph or page? Are there instructions, help screens, or examples of the desired data necessary to fill out a form? Does the site make clear when you *leave* the site and go to an external site?
Does the site have multi-lingual capabilities? Are there links to online help, webmasters, or places to leave questions or ask for assistance? Is the site properly identified in terms of ownership, authorship, and responsibility for content and date of creation/revision? Additional resources available at http://library.pittstate.edu/staff/susan/adamotor.html.
Does the site have music? If so, is it very clear early on how to turn it on or off? (sometimes more important for seniors with hearing aides than it is for the profoundly deaf!) If sound bytes, or video clips are resident on the site, are the resulting dialogs, songs, or description of the type of sound readily available in a close-captioned mode so that the profoundly deaf can experience or "hear" a description of the sound byte or video action.
Are navigation or success cues given with sound, or a beep, such as at the finish of loading a program, or the notation that an order has been successfully placed, or a greeting card successfully sent? If sound cues or beeps are the sole notification that x has occurred, then visual cues must also be present with the sound cue.
The following is a select list of references, most available online, which may provide further attention and detail. While much of the literature relates specifically to library web pages, they are universally applicable to departmental and campus web pages as well. Additionally, a series of links is available at http://library.pittstate.edu/staff/susan/ada.html to other products and sites.
Bernard, M (2001), How can I make my site more appealing to international users?, Criteria for Optimal Web Design (Designing for Usability), Summer 2001, http://psychology.wichita.edu/optimalweb/international.htm (Accessed June 26, 2007).
Bernard, M., M. Mills, M. Peterson, and K. Storrer, (2001), A comparison of popular online fonts : which is best and when?, Usability News, V.3, No.2, Summer 2001, http://psychology.wichita.edu/surl/usabilitynews/3S/font.htm (Accessed June 26, 2007).
Blake, S. (2000), Universal access, the ADA, and your library web page, Arkansas Libraries, Vol. 57, No. 1, p. 19-24.
Burstein, C. (2001), Testing and considerations, Viewable with Any Browser, http://www.anybrowser.org/campaign/abdesign3.html (Accessed June 26, 2007).
Craven, J. (2000), Electronic access for all: awareness in creating accessible web sites for the university library, Disability and Information Systems in Higher Education (DISinHE). Available: http://www.dmag.org.uk/resources/casestudies/cravenfull.asp (Accessed June 26, 2007).
Deines-Jones, C. (1995), Access to library internet services for patrons with disabilities : pragmatic considerations for developers, Information Technology and Disabilities, Vol. 2, No. 4, http://www.rit.edu/~easi/itd/itdv02n4/article5.htm (Accessed September 7, 2007).
Edwards, K., I. Van Mele, M. Verheust, and A. Spaepen (1997), "Evaluation of user interface design to optimize access to library databases for people who are motor impaired," Information Technology and Libraries, Vol. 4, No. 4, p. 175-181.
Herrell, A. (2001), Accessibility : the politics of design, A List Apart, http://www.alistapart.com/politics/ (Accessed June 26, 2007).
Koch, P. (2000), "Fear of Style Sheets 3: A New Era", A List Apart, http://www.alistapart.com/articles/fear/ (Accessed June 26, 2007).
Laux, L. (1998), Designing web pages and applications for people with disabilities, in C. Forsythe et al (eds), Human Factors and Web Development, Mahway NJ : Lawrence Erlbaum Associates, Inc., p.87-95. ISBN 0-8058-2824-9.
Lilly, E. and C. Van Fleet (2000), Measuring the accessibility of public library home pages, Reference and User Services Quarterly, Vol. 40, No. 2, p. 156-165.
Milne, Scott (2002), Implementing Skip Navigation, http://www.dmag.org.uk/resources/design_articles/skip.asp (Accessed June 26, 2007).
McMillan, W. (1992), Computing for Users with Special Needs and Models of Computer-Human Interaction, p. 143-148, in Conference on Human Factors in Computing Systems, CHI 92, pp. 143-148, Reading, MA: Addison Wesley. ISBN 0-201-53344-X.
McNulty, T. and E. Stedfeld, (1999), Making a web page more accessible with Bobby : A case study of NYU's Bobst Library, in T. McNulty (ed) Accessible Libraries on Campus : A Practical Guide for the Creation of Disability-Friendly Libraries, Chicago, IL : Association of College and Research Libraries, American Library Association. ISBN 0-8389-8035-X.
Morrell, R. and K. Echt (2001), Presenting information to older adults, Journal of Museum Education, Vol. 26, p. 10-12.
Nielson, J. (2000), Accessibility for users with disabilities, in Designing Web Usability. Indianapolis, IN : New Riders Publishing, p. 298-311. ISBN 1-56205-810-X.
Oakley, A. (1996), Colour Blind Design Hints and Tips, http://www.cimmerii.demon.co.uk/colourblind/design.html. (Accessed June 26, 2007).
Paciello, M. (2001), Web Accessibility: 500 Million and Growing, Webreview March 16, 2001, http://www.ddj.com/dept/architect/184412393 (Accessed June 26, 2007).
Paciello, M. (2000), Web Accessibility for People with Disabilities, Lawrence, KS : CMP Books. ISBN 1-929629-08-7.
Quinn, A. (2001), Why 'Bobby Approved' does not always mean accessible, Frontend.Com Usability InfoCentre, http://infocentre.frontend.com/infocentre/articles/whybobbyapproveddoesnotalwaysmeanaccessible.html(Accessed June 26, 2007).
Rigden, C. (1999), Safe web colours for colour-deficient vision. British Telecommunications Engineering, Vol. 17, http://www.btplc.com/age_disability/technology/RandD/colours/index.htm (Accessed June 26, 2007).
Sloan, D. (2000), How to Uncover a Web Site's Accessibility Barriers, http://www.dmag.org.uk/resources/design_articles/howtojudge.asp (Accessed June 26, 2007).
World Wide Web Consortium (2001), User Agent Accessibility Guidelines 1.0, http://www.w3.org/TR/UAAG/ (Accessed June 26, 2007).
Wolfmaier, T. (1999), Designing for the color-challenged : a challenge, Internetworking, Vol. 2, No. 1, http://www.InternetTG.org/newsletter/mar99/accessibility_color_challenged.html (Accessed June 26, 2007).
Zajicek, M. and S. Hall (2000), Solutions for elderly visually impaired people using the internet, in S. McDonald et al. (eds.) People and Computers XIV - Usability or Else! Proceedings of HCI 2000 , London, UK : Springer Verlag. ISBN 1-85233-318-9.
Note: This page has updated url links revised June 26, 2007.
Send comments to: suzyq@pittstate.edu
Susan M. Johns-Smith
Axe Library
Pittsburg State University
1605 South Joplin Street
Pittsburg, KS 66762
Phone: 620-235-4115
This page last updated Tuesday, 09-Oct-2007 20:08:43 CDT