Printer-friendly Version


Tennessee Libraries

Volume 56 Number 1



Accessibility and the Virtual Library

Celia Szarejko

Systems Librarian, East Tennessee State University




Browsing through the computer books in the local Barnes & Noble bookstore in late fall 2003, I discovered Jeffrey Zeldman's Designing with Web Standards (2003). His use of the New York Public Library Web site as an example of good design using Web standards was what really captured my attention. Subsequent discovery of A List Apart (2006) and the CSS Zen Garden (n.d.) provided the tools, motivation and inspiration to embark in 2004 on a project to overhaul and redesign the Sherrod Library Website at East Tennessee State University (ETSU) to apply the principles in practice. Design goals, not yet fully achieved, included improving the site's usability and accessibility and are the subject of this paper.

Standards-based Web design separates content, presentation, and behavior, with XHTML replacing HTML for structured content markup, Cascading Style Sheets (CSS) for presentation, and ECMAScript 262, "the standard version of JavaScript" for behavior (Zeldman 2003, 53-57). The challenges are many and the learning curve is not flat, but the end result is flexible Web pages whose content can be presented in different ways on different devices to suit the needs and preferences of the user, a key requirement for accessibility.

What is Web Accessibility?

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) (2005a) defines Web accessibility to mean "that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility encompasses all disabilities that affect access to the Web, including visual, auditory, physical, speech, cognitive, and neurological disabilities."  

Visual disabilities include blindness, low-vision, and color-blindness. Design issues like text resizing, color choice, and contrast between text and background need to be considered. Auditory disabilities (deaf and hard-of-hearing) would require an accommodation like captioning if your Web site includes media (audio or video with soundtrack). Physical disabilities like the inability to use a mouse or keyboard or motor impairments that make it difficult to use an input device need to be taken into account when you consider navigation, scrolling, filling in forms, and timeout settings in things like web catalogs. Cognitive disabilities like dyslexia may be accommodated by screen reader software, which also makes web text accessible to those who cannot read.

A disability may be temporary: a break or sprain that prevents normal use of hand or arm, deteriorating vision due to old age, etc. Able users may become disabled through the effects of age, accident, or disease. 

Accessibility is related to the larger concept of usability, which "means designing a user interface that is effective, efficient, and satisfying" (Henry 2002a, 7-31). It is possible to design a Web page that is accessible but not usable. A common example used to illustrate this point is alternative text supplied for an image that fails to convey the meaning of the image in the context of the page, such as using the file name "logo.gif" instead of a functional description of the image like "Library Home Page." The alternative text makes the image accessible, but unless it conveys meaning it is not usable. The goal for effective Web design should be what Shawn Lawton Henry (2002a, 8) calls "usable accessibility," which goes beyond checking Web pages for compliance with coding standards or guidelines and actually tests pages with various assistive technologies and includes users with disabilities as participants in testing.

Byerley and Chambers (2002, 177), in their report on the results of their study involving users with visual impairments in testing the accessibility of the OCLC FirstSearch and Gale InfoTrac Web interfaces, come to the same conclusion:

"We have seen from our study that accessibility does not necessarily equate with usability. If we accept the idea that product usability is as important as accessibility, then approaching accessibility from a human perspective truly embodies the spirit and not simply the letter of the law. Just as usability studies of Web sites are conducted with visual Web users, our study indicates that they also need to be conducted with auditory users, who rely on assistive technologies to access Web-based products. As we have seen, a Web page can be accessible without being user-friendly."

The first phase of the Sherrod Library redesign project did not include disabled users or use assistive technologies in testing. The next phase will address that deficiency and involve participants recruited through the university's Office of Disability Services.

Web Accessibility Law, Guidelines and Standards

In the United States, the Americans with Disabilities Act of 1990 (ADA) and Section 508 of the Rehabilitation Act Amendments of 1998 (Section 508) are the main pieces of federal legislation that apply to the design of Web sites. According to Dr. Cynthia D. Waddell, a recognized expert in the area of US Web accessibility law, "Under the ADA, covered entities are required to furnish appropriate auxiliary aids and services where necessary to ensure effective communication with individuals with disabilities, unless doing so would result in a fundamental alteration to the program or service, or an undue burden....On September 9, 1996, the US Department of Justice (USDOJ) issued a policy ruling applying the ADA to the Internet. Under the rationale of 'effective communication,' the USDOJ Letter states that State and Local Governments (ADA Title II), as well as Public Accommodations (nongovernmental) and Commercial Facilities (ADA Title III), must provide effective communication whenever they communicate through the Internet" (Waddell 2002, 332).

ADA legislation did not include standards for evaluating Web site accessibility. To date, "there have been no legal challenges under the ADA on the issue of inaccessible web pages, However, there have been many ADA accessible web complaints ... and many have settled" (Waddell 2002 333, 335). The complaint of greatest interest to libraries is the California Office of Civil Rights (OCR), US Department of Education, OCR Letter of Resolution, Docket No. 09-97-2002 (April 7, 1997) concerning "a student complaint that a university failed to provide access to library resources, ..." (Waddell 2002, 336). The essential points made here are that disabled users are entitled to the same level of access to Internet resources as non-disabled users; providing services to  disabled users needs to be more systematic than ad hoc by including their needs in planning; and "when an entity selects software programs and/or hardware equipment that is not adaptable for people with disabilities, 'the subsequent substantial expense of providing access is not generally regarded as an undue burden when such cost could have been significantly reduced by considering the issue of accessibility at the time of the initial selection'" (Waddell 2002, 337).

Section 508 of the 1998 Amendments to the Rehabilitation Act of 1973 require that federal departments and agencies ensure that electronic and information technology be accessible to both employees and members of the public with disabilities to the extent that it does not impose an "undue burden." The law applies to development, procurement, maintenance, or use of electronic and information technology by the federal government and so applies to federal government agency and department Web pages. It does not apply to private industry web pages unless they are part of a product or service being procured by the federal government (United States Access Board undated).  The idea is that the federal government will influence private industry compliance with accessibility requirements through its procurement practices.

The development of standards and guidelines for accessible Web design emerged first in the international community. The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) developed the Web Content Accessibility Guidelines (WCAG) 1.0, published by the W3C as a Recommendation in May 1999 (W3C 1999b). These guidelines are international in scope and were developed by consensus among academic researchers, members of the disabled community, and the commercial sector. Compliance with the guidelines is voluntary. There are 14 guidelines, each of which has one or more checkpoints that describe how the guideline is applied in Web design with links to techniques and examples intended to provide implementation guidance. Each checkpoint is assigned one of three priorities that can be characterized by a key verb: Priority 1=must, Priority 2=should, Priority 3=may.  W3C WAI accessibility compliance levels correspond with the WCAG 1.0 priorities: Level A satisfies all Priority 1 checkpoints, AA satisfies Priority 1 and 2 checkpoints, and AAA satisfies all three priority level checkpoints. The WCAG 1.0 Checklist (W3C 1999a) is the easiest format for a Web developer to use as a guide for the level of compliance they wish to achieve because it organizes the checkpoints by priority. Version 2 of the guidelines "is being developed to apply to different Web technologies, be easier to use and understand, and be more precisely testable," and completion of the guidelines is anticipated in 2006 (W3C WAI 2005b).

The United States Access Board is the independent federal agency that developed the standards used to determine whether or not a technology covered by Section 508 is accessible. The standards were published on December 21, 2000 (United States Access Board n.d.). The 16 functional standards that apply to Web pages are in Subpart B-Technical Standards § 1194.22 Web-based intranet and internet information and applications (a) through (p), reproduced from the United States Access Board Web Section 508 Web site (2000) in Appendix A. In explaining the difference between WCAG 1.0 and the US Access Board standards, Waddell (2002) notes that § 1194.22 (a) through (i) are essentially the same as in WCAG 1.0, and (j) and (k) "were meant to be consistent with WCAG 1.0, but the US Access Board needed to use language consistent with enforceable regulatory language. Rules § 1194.22(l), (m), (n), (o) and (p) are different from WCAG 1.0 due to the need to require a higher level of access or prescribe a more specific requirement." She also identifies the four Priority 1 WCAG 1.0 Checkpoints that were not adopted by the US Access Board and the rationale for their exclusion. A useful comparison chart showing both the Section 508 standards and WAI guidelines with commentary produced by Jim Thatcher is available at his Web site (Thatcher 2005a).

WCAG 1.0 overlaps with, but is not identical to,the standards that were developed by the United States Access Board to measure compliance with Section 508 of the Rehabilitation Act Amendments of 1998. Compliance with WCAG 1.0 and Section 508 are not the same thing.

State and local government agencies may choose to adopt Section 508 standards as a way to demonstrate Web accessibility as required by ADA and Section 504 of the Rehabilitation Act of 1973 that prohibits discrimination against disabled persons by entities, programs, or activities that receive federal funds. Some states (not Tennessee) have adopted WCAG for ADA-compliance. According to the State of Tennessee's official Web site (Tennessee n.d.), "Tennessee executive branch agency Web sites are subject to the same accessible Web standards as federal agencies. Section 508 of the Federal Register establishes requirements for federal electronic and information technology, and the federal Access Board has issued the standards to meet those requirements."

Given that the Section 508 standards define what it means for a US Web site to be accessible and ADA requires that Web sites be accessible for "effective communication," Waddell (2002,  346) recommends that Web developers adopt Section 508 standards in addition to WCAG as a "best practice."

The most compelling reason to undertake accessible Web design is to reach the largest possible audience efficiently. Following current standards to separate content, presentation, and behavior makes it comparatively easy to change the way your site displays on different devices without having to create multiple versions of the site. Accessible Web pages work with slow Internet connections, handheld devices (PDAs, Web-enabled phones), and text-only browsers (Moss 2004a), and have the added benefit of being optimized for search engine indexing and ranking (Hagans 2005).

Web Accessibility and Libraries

It is easiest to incorporate accessibility requirements in the design of new pages and essential to incorporate them in the redesign or update of old pages. Ideally, usability testing including disabled users would be part of the effort. Priorities for updating old pages could be determined from Web server access log statistics with the most frequently used pages done first. Other advice (Clark 2002) is to develop and post an accessibility policy and provide a contact for users who have a problem. The lack of a posted accessibility policy is another deficiency that needs to be corrected on the Sherrod Library site.

While libraries do not control the design of the software products they purchase, an awareness of accessibility issues could be incorporated into the selection criteria that drive purchasing decisions. Lewis and Klauber (2002, 140) suggest that users with disabilities be involved in selecting and purchasing software and suggest including accessibility as a factor in product selection. Information about the accessibility of online database products and content and the quality of the information provided varies widely. Thomson Gale's Electronic Product Accessibility Policy (2005) and OCLC's Section 508 Accessibility Template for FirstSearch (2002) provide detailed information about product compliance with Section 508 standards. Project MUSE ([2003?]), JSTOR (2005), and Science Direct (2005) provide general summaries, while Emerald (Undated) and Oxford Reference Online (Undated) are rather ambiguous.
The extent to which the Web interface to a software product can be customized by the purchaser would determine the extent to which a library could address accessibility-related problems if the vendor were unwilling to do so. Axtell and Dixon (2002) evaluated the 2000 release of the Voyager Web catalog, WebVoyage, for accessibility by visually disabled users and recommended modifications that would need to be done by both the software vendor and libraries that use the product. The global timeout setting in WebVoyáge and the lack of a visible timer and mechanism for the user to request more time are accessibility issues for users with motor impairments.

Does your Web site include links to documents in Adobe Portable Document Format (PDF)? Did you know that there are problems with PDF and accessibility? The extent to which PDF constitutes a barrier to accessibility and two approaches to dealing with the problem (providing an HTML equivalent or creating a tagged PDF file) are discussed on the WebAIM Web site (2005). Joe Clark (2005) explores the issue in greater depth and expresses the opinion that PDF is not as inaccessible as it is made out to be. A third approach that I have not seen discussed in the accessibility literature involves scanning a PDF with an optical character recognition (OCR) layer, a technique that EBSCO Publishing has been using since September 2004 to make PDFs readable with screen reader software (EBSCO 2005a). Since the Sherrod Library Web site contains few pages in PDF format, creating tagged PDF files would be our preferred approach.

Libraries have the greatest control over incorporating accessibility into the Web pages they create themselves. Customizing the Web interfaces of other products (e-journal management systems, link resolvers, federated search engines, library catalogs) is a challenge because the design of the software imposes constraints on what is achievable and how it is achieved. Customization also has to be maintained through upgrades. Both creation and customization require an investment in tools and training for library Webmasters; the quality of the end result depends on the skills and experience of the craftsman as well as on the extent and quality of the tools they use.

Training, Role Models, and Testing Tools

Web Accessibility in Mind's Web site ( is an excellent place to start. The site covers current developments in the field of Web accessibility including legislation, design principles and tools, research on disabilities, and new technologies. The site is searchable, well-organized, and well-structured. WebAIM has what I think is the best one-page summary of products and tools for building accessible Web sites.

Pennsylvania State University's site, Accessible on the Web (2005), is another good starting point for training, tools, and resources on the topic of accessible Web design and Section 508 standards in terms of content. It is comprehensive, well-organized, and includes links to other excellent resources not included in the WebAIM site, such as A List apart and Jim It lacks a search tool, making it difficult to locate information on specific topics.

The University of Washington Health Sciences Libraries site, HealthLinks (2005a), is an excellent example of a library site designed to improve "usable accessibility" using Web standards. It features markup in XHTML, styling with CSS, text that can be resized in the browser, and liquid layout, to name a few features. It also includes a posted accessibility policy.(2005b).

A-Prompt, from the Adaptive Technology Resource Centre (ATRC) of the University of Toronto, may be downloaded from and is included on the CD-ROM that accompanies Joe Clark's book (Clark 2002).

HiSoftware®  Cynthia Says (TM) Portal is an online testing tool that checks one page at a time. The AccVerify® and AccRepair® software products from this vendor are available for purchase and are integrated with Microsoft FrontPage®.  More information about the commercial products is available at the vendor's Web site.

LIFT from UsableNet, Inc. provides Web site testing software products for servers and desktop applications, including both Macromedia/Adobe Dreamweaver and Microsoft FrontPage. It also offers a Web-based service.

Watchfire WebXACT used to be Bobby from the Center for Applied Special Technology (CAST). Bobby is the validation tool most frequently mentioned in the library literature and in statements by database vendors (EBSCO 2005b, Thomson Gale 2005, Project MUSE 2003) about testing their products for accessibility. Joe Clark (2002) has nothing good to say about it, Jim Thatcher (Thatcher et al. 2002) is far less negative, and Lemon (2005) says "the number of false positives reported by the validator make it the worse [sic] of the current crop."

The WAVE 3.0 Accessibility Tool from WebAIM: Web Accessibility in Mind (n.d.) offers four methods of use: submit a page URL, upload a page, install one or more browser toolbars (the toolbar is available for Netscape, Microsoft Internet Explorer, or Mozilla), or add a bookmarklet to the browser to "WAVE This Page." 

Incorporating accessibility and usability into Web page design requires effort by trained humans. The free accessibility validators available on the Internet are effective in checking for some coding errors but all have their limitations, showcased by Gez Lemon (2005) who created a test document containing known errors and ran it through five of them (including Cynthia Says, WAVE, and WebXACT) with the result that "None of them successfully found any of the errors, with one of them reporting an error that didn't exist."  Henry (2002b) and Moss (2005) make the point that these free tools help in identifying coding errors, improving evaluation efficiency, but are no substitute for human judgment.  Jim Thatcher (2005b), in his response to the Lemon article, suggests that the same tests performed using commercial versions of accessibility validation software might produce better results. In his chapter on testing for Section 508 compliance (Thatcher et al. 2002, 164-188) he examines each of the Section 508 guidelines that apply to Web sites and discusses what can be tested for "œalgorithmically" by an automated tool and what requires "judgment."  He also provides a detailed comparison of the results produced by the free Web-based version of Bobby from the Center for Applied Special Technology (CAST) and LIFT from UsableNet, noting that each tool has different strengths and that the commercial version of LIFT does, indeed, produce more complete and accurate results than the free one.

In an August 8, 2005, follow-up posting to his article, Lemon recommends testing pages using the Web Accessibility Toolbar for Microsoft Internet Explorer, developed by and available from Vision Australia (2005-2006), and Chris Pederick's Web Developer extension for Firefox and Mozilla. Both tools allow a developer to turn images, styles, and scripting off to verify functionality without those features.


As browser and Web authoring tools improve in supporting Web standards, the task of developing accessible Web sites should get easier. It would be interesting to evaluate the accessibility of Web sites produced by Content Management System (CMS) software to see if its use makes it easier to produce accessible pages. At present, libraries can improve the accessibility of their Web presence by adopting standards-based design and including their disabled community in usability testing of both locally authored Web pages and the Web-based databases, catalogs, and other systems that they purchase. The results would benefit everyone.


Appendix A

United States Access Board. 2000. Electronic & information technology accessibility standards (Section 508). (accessed December 21, 2005)
Subpart B -- Technical Standards
§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
(g) Applications shall not override user selected contrast and color selections and other individual display attributes.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
§ 1194.22 Web-based intranet and internet information and applications.
(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
(d) Documents shall be organized so they are readable without requiring an associated style sheet.
(e) Redundant text links shall be provided for each active region of a server-side image map.
(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
(g) Row and column headers shall be identified for data tables.
(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
(i) Frames shall be titled with text that facilitates frame identification and navigation.
(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
(k) A text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
(o) A method shall be provided that permits users to skip repetitive navigation links.
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
Note to §1194.22: 1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:
Section 1194.22 Paragraph
WCAG 1.0 Checkpoint
2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section. WCAG 1.0 is available at



Reference List

A List apart. 2006. (accessed January 12, 2006).

Axtell, Robert and Judith M. Dixon. 2002. Voyager 2000: a review of accessibility for persons with visual disabilities. Library Hi Tech 20, no. 2, 141-147.

Byerley, Suzanne L. and Mary Beth Chambers. 2002. Accessibility and usability of Web-based library databases for non-visual users. Library Hi Tech 20, no. 2, 169-178.

Clark, Joe. 2003. Building Accessible Websites. Indianapolis: New Riders Publishing. Also available online at (accessed January 4, 2006).

------. 2005. Facts and opinions about PDF accessibility. A List Apart No. 201 (August 22). (accessed January 5, 2006).

css Zen Garden: The Beauty in CSS Design. n.d. (accessed December 12, 2005).

EBSCO Publishing. EBSCOhost Support. 2005a. Are EBSCOhost PDFs ADA compliant? (accessed December 12, 2005).

EBSCO Publishing. EBSCOhost Support. 2005b. Is EBSCOhost Web or EBSCOhost Web Text Only FAR Section 508/ADA-compliant?  (accessed December 12, 2005).

Elsevier B.V. 2005. Accessing ScienceDirect. (accessed December 12, 2005).

Emerald Group Publishing Limited. n.d. Emerald accessibility. (accessed December 12, 2005).

Hagans, Andy. (2005). High accessibility is effective search engine optimization. A List Apart No. 207 (November 8), (accessed January 4, 2006).

Henry, Shawn Lawton. 2002a. Understanding Web accessibility. In Constructing Accessible Web Sites, by Jim Thatcher, Paul Bohman, Michael Burks, Shawn Lawton Henry, Bob Regan, Sarah Swierenga, Mark D. Urban, and Cynthia D. Waddell. Birmingham, UK: glasshaus.

------. 2002b. Web accessibility evaluation tools need people. (accessed January 4, 2006).

HiSoftware. 1996-2006. HiSoftware website quality testing solutions home. (accessed January 5, 2006).

------. 2003-2006. Welcome to the HiSoftware Cynthia Says Portal. (accessed January 5, 2006).

JSTOR. 2005. JSTOR and accessibility. (accessed January 12, 2006).

Lemon, Gez. 2005. Testing invalid content with accessibility validators. Juicy Studio (August 7), (accessed January 4, 2006).

Lewis, Valerie and Julie Klauber. 2002. [Image] [Image] [Image] [Link] [Link] [Link]: inaccessible Web design from the perspective of a blind librarian. Library Hi Tech 20, no. 2, 137-140.

Moss, Trenton. (2004a). How to sell accessibility. sitepoint (April 6), (accessed January 4, 2006).

Moss, Trenton. (2004b). What is Web accessibility? A List Apart No.179 (April 30), (accessed January 4, 2006).

Moss, Trenton. (2005). The problem with automated accessibility testing tools. (accessed January 5, 2006).

OCLC FirstSearch. 2002. OCLC Section 508 accessibility template. (accessed December 12, 2005).

Oxford Reference Online. n.d. ORO: Oxford Reference Online: Oxford Reference Online FAQs. (accessed December 12, 2005).

Pederick, Chris. 2003-2006. Web developer extension. (accessed January 19, 2006).

Pennsylvania State University. 2005. Accessible on the Web. (accessed December 12, 2005).

Project MUSE. [2003?]. Accessibility and "Section 508." (accessed December 12, 2005).

Tennessee, State. n.d. accessibility. (accessed December 22, 2005).

Thatcher, Jim. 2005a. Comparison WCAG and Section 508 Web. (accessed December 22, 2005).

------. 2005b. An exploding myth. Reaction to Testing invalid content with accessibility validators by Gez Lemon, posted August 7, 2005. (accessed January 4, 2006).

------. 2005c. Web accessibility for Section 508.  (accessed December 12, 2005).

Thatcher, Jim, Paul Bohman, Michael Burks, Shawn Lawton Henry, Bob Regan, Sarah Swierenga, Mark D. Urban, and Cynthia D. Waddell. 2002. Constructing Accessible Web Sites. Birmingham, UK: glasshaus.

Thomson Gale. Technical & Training Resources. 2005. Thomson Gale's electronic product accessibility policy. (accessed December 12, 2005).

United States Access Board. 2000. Electronic & information technology accessibility standards (Section 508). (accessed December 21, 2005).

------. n.d. Electronic and information technology standards: An overview. (accessed December 21, 2005).

University of Toronto Adaptive Technology Resource Centre (ATRC). n.d. A-Prompt. (accessed January 5, 2006).

University of Washington Health Sciences Libraries. 2005a. HealthLinks. (accessed December 12, 2005).

------. 2005b. HealthLinks accessibility, standards, and browser support.  (accessed December 12, 2005).

UsableNet Inc. 2004. LIFT Online 5 pages free trial. (accessed January 5, 2006).

------. 2006. Choose the right LIFT product. (accessed January 5, 2006).

Vision Australia. 2005-2006. Web accessibility toolbar. (accessed January 19, 2006).

Waddell, Cynthia D. 2002. US Web accessibility law in depth. In Constructing Accessible Web Sites, by Jim Thatcher, Paul Bohman, Michael Burks, Shawn Lawton Henry, Bob Regan, Sarah Swierenga, Mark D. Urban, and Cynthia D. Waddell. Birmingham, UK: glasshaus.

Watchfire Corp. 2003-2004. Watchfire WebXACT. (accessed January 6, 2006).

WebAIM: Web Accessibility in Mind. 2006. Defining Adobe PDF accessibility. (accessed January 12, 2006).

------. n.d. WAVE 3.0. (accessed January 5, 2006).

World Wide Web Consortium (W3C). 1999a. Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0. (accessed December 21, 2005).

------. 1999b. Web Content Accessibility Guidelines 1.0. (accessed December 21, 2005).

------. 2005. Web Accessibility Initiative (WAI). (accessed December 21, 2005).

World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). 2005a. Introduction to Web accessibility. (accessed December 21, 2005).

------. 2005b. Web Content Accessibility Guidelines (WCAG) Overview. (accessed December 21, 2005).

Zeldman, Jeffrey. 2003. Designing with Web Standards. Indianapolis: New Riders Publishing.



Contact Us

P.O. Box 241074
Memphis, TN 38124-1074
Phone: 901-485-6952

Copyright © 2011 Tennessee Library Association. All Rights Reserved.