UNLOCKING THE KINGDOM GATES: DESIGNING WEB SITES FOR ACCESSIBILITY
UNLOCKING THE KINGDOM GATES: The purpose of these guidelines is to identify and describe the web design features of the Web Accessibility Initiative of the W3C and demonstrate strategies for authoring web pages that include accessibility features. At Media Lab of the Life Span Institute at the University of Kansas, we are incorporating the W3C web design principles and strategies into all new web sites that we develop.
Web accessibility is based on design principles that provide for the development of web pages that accommodate the needs of a broad range of users, computers, and telecommunications systems without regard to age or disability. When a web site is accessible, anyone browsing the site should be able to gain a complete understanding of the information presented on the site as well as have an undiminished ability to interact with the site. Since many educators are commonly authoring on-line courses or publishing research findings in web pages, they need to apply the design strategies of the Web Content Accessibility Guidelines to the development of web pages that facilitate accessibility for web surfers with disabilities.
Most web pages do not allow for the eventuality that some web surfers may not see, hear, move, or process some types of information, may have difficulty reading or comprehending text, or may not have, or be able to use, a mouse or keyboard. When one considers that nearly 54 million Americans have some kind of disability (National Council on Disability, 1997), it would be reasonable to assume that considerable attention is given to the design of web pages that are accessible to everyone. Nevertheless, this segment of the population has among the lowest rates of use of these technologies and the problem is largely one of access (Kaye, 2000).
People with disabilities often have the most to gain from new technologies of the information age because computer technology and the Internet have the potential to enhance their lives and increase their independence. For example:
Many experienced web designers, however, are completely unaware of accessibility issues and, therefore, have little or no experience in making their web pages usable by persons who cannot see the screen or use a mouse the same way they do. Most web authors have what Bartlett (1999) calls a "skewed mindset" in which they develop web pages to convey content visually. They do not consider that the average web surfer who is blind does not see any of the sophisticated graphics, animation, and text layout on the screen and does not use a visually-oriented input system such as a mouse. While adjusting browser preferences and using assistive technologies may lower the access barriers, the best method for providing equal accessibility to a web site is by building accessibility features into the web site itself (Casey, 1999).
The World Wide Web Consortium (W3C) has recognized a disparity in accessibility to the Web between persons with and without disabilities and has responded by developing a set of web design standards and strategies that specifically address the issue of web accessibility. Web accessibility is based on design principles that provide for the development of web pages that accommodate the needs of a broad range of users, computers, and telecommunications systems without regard to age or disability.
When a web site is accessible, anyone browsing the site should be able to gain a complete understanding of the information presented on the site as well as have an undiminished ability to interact with the site. Since many educators are commonly authoring on-line courses or publishing research findings in web pages, they need to implement and apply the design strategies of the Web Content Accessibility Guidelines to the development of web pages that facilitate accessibility for web surfers with disabilities.
Web accessibility is an issue that must be confronted by site developers and page authors. In a recent opinion from the U.S. Department of Justice (see http://www.internetlawyer.com/ada.htm), the Americans with Disabilities Act (ADA) also applies to cyberspace. According to this opinion, entities covered by the ADA that use the Internet for communications regarding programs, goods, or services, must be prepared to provide these communications through accessible means as well. Additionally, Section 508 of the U.S. Rehabilitation Act requires federal departments and agencies to evaluate the extent to which their electronic and information technology is accessible to and usable by individuals with disabilities (see www.508.org).
Organizational or institutional computing policies and guidelines need to make provision for web accessibility although many may not do so. The University of Kansas Netiquette Guide recommends that web page authors need to make their pages accessible to the entire user community in order to be in compliance with the ADA. Thus, web accessibility is quickly becoming a compliance issue. Therefore, web page authors need to be concerned and become informed.
The purpose of this tutorial is to provide instruction for creating well-designed web pages based on the recommendations of the Web Accessibility Initiative of the W3C. Specifically, this tutorial targets and demonstrates strategies that improve accessibility for persons with visual impairments.
Web pages or sites that are accessible to people with disabilities are highly accessible to everyone. Thus, web accessibility is a design issue. Design strategies that create accessible web pages also facilitate the creation of well-designed web pages. The additional time and labor that may be required to make a web page or web site accessible is energy spent in creating a well-designed web page or site. So improvements to a web page or site that enable web surfers with disabilities improves the web page or site for all web surfers.
As the use of the Web is perceived to be an effective tool for dissemination of research findings or for the provision of asynchronous instruction, the issue of accessibility of web page information will become more relevant. The World Wide Web Consortium has embraced the issue of accessibility through its Web Accessibility Initiative and essentially thrown open the gates to the virtual kingdom for persons with disabilities. Although the provision of accessibility features in web pages intensifies the labor requirements for authoring web pages, the implications of accessibility features for sound web page design are a benefit that offsets the additional time and labor required to author accessible web pages. Because of the commitment of the W3C to web accessibility, the statutory requirements that ensure equal opportunity and access for persons with disabilities, and the preponderance of resources available for web authors to use in the development of accessible web pages, new and experienced web authors have a compelling mandate for including accessibility features in web pages.
Who Is the World Wide Web Consortium?
In October 1994, Tim Berners-Lee, inventor of the Web, founded the World Wide Web Consortium (W3C) at the Massachusetts Institute of Technology, Laboratory for Computer Science [MIT/LCS] The W3C was created to promote and manage its evolution and to ensure its interoperability. The W3C has more than 400 Member organizations from around the world and is financed by its members and by public funds. W3C Membership in the W3C is available to any organization.
The W3C is hosted by MIT/LCS in the United States; the Institut National de Recherche en Informatique et en Automatique (INRIA) in Europe; and the Keio University Shonan Fujisawa Campus in Japan. Many of the more than fifty researchers and engineers that make up the W3C Team work at these three host locations.
The activities of the W3C are generally organized into groups: Working Groups (for technical developments), Interest Groups (for more general work), and Coordination Groups (for communication among related groups). These groups, made up of representatives from Member organizations, the W3D Team, and invited experts, produce most of W3C's results: technical reports, open source software, and services (e.g., validation services). These groups also ensure coordination with other standards bodies and technical communities. There are currently over thirty W3C Working Groups.
W3C activities and other work are organized into four domains: 1) Architecture Domain to develop the underlying technologies of the Web; 2) User Interface Domain to improve user interaction with the Web including work on formats and languages that will present information to users with more accuracy and a higher level of control; 3) Technology and Society Domain to confront issues that arise from applications of Web technology; and 4) Web Accessibility Initiative (WAI)--W3C's commitment to promote a high degree of usability for people with disabilities.
The W3C has published more than twenty Recommendations since its inception. Each Recommendation not only builds on the previous, but is designed so that it may be integrated with future specifications as well. These Recommendations allow the W3C to transform the architecture of the initial Web (essentially HTML, URIs, and HTTP) into the architecture of tomorrow's Web that will be based on a foundation of Extensible Markup Language (XML).
In April, 1997, the W3C created the Web Accessibility Initiative (WAI) as an official activity under the Technology and Society domain of the W3C. The WAI is funded separately from other W3C member activities and is sponsored by representatives of web development industries, disability organizations, research organizations, and government. Some of the WAI sponsors include the National Science Foundation (NSF), National Institute on Disability and Rehabilitation Research (NIDRR), Microsoft, IBM, Lotus Development, and NCR.
To facilitate the efforts for promoting Web accessibility, the WAI joined forces with the W3C HTML Working Group in the design of HTML 4.0 and in December, 1997, HTML 4.0 became a W3C recommendation (see www.w3.org/TR/REC-html40/). Additionally, in May, 1998, an official W3C recommendation for Cascading Style Sheets, Level 2, (CSS2) was issued (see www.w3.org/TR/REC-CSS2/). In May, 1999, the WAI issued the Web Content Accessibility Guidelines 1.0 ( see www.w3.org/TR/WAI-WEBCONTENT/). These guidelines incorporated the recommendations of HTML 4.0 and CSS2 and were intended for use by all web content developers including page authors, site designers, and developers of authoring tools.
Each of the 14 guidelines of the WCAG is comprised of multiple checkpoints or sub-guidelines. Assigned to each of the checkpoints is a priority level that is based on the checkpoint's potential impact on accessibility. Priority 1 checkpoints are "must satisfy" requirements without which some groups will find it impossible to access information in a web page. Priority 2 checkpoints are "should satisfy" requirements without which one or more groups will find it difficult to access information in a web page. Priority 3 checkpoints are "may address" requirements without which one or more groups will find it somewhat difficult to access information in a web page.
The WCAG provide for three levels of conformity to the guidelines: Level A, AA, and AAA. For Level A conformity, all Priority 1 checkpoints are satisfied; for Level AA all Priority 2 checkpoints are satisfied; for Level AAA all Priority 3 checkpoints are satisfied. Conformance levels are cumulative. For example, Level AAA conformance would indicate that a web page conforms to Priority 1, 2, and 3 checkpoints. Web pages can display logos to indicate a claim of conformance to a specified level of conformity with the WCAG 1.0.
The primary purpose of this tutorial is to identify and demonstrate to new and experienced web authors a set of web page design principles that incorporate the accessibility features of the Web Content Accessibility Guidelines (WCAG). The WCAG consist of 14 guidelines that are formulated around two general web page design strategies: (1) ensuring graceful transformation, and (2) making content understandable and navigable.
Web surfers may operate in contexts very different from the one in which a web page is developed. The WCAG support and promote the development of pages that transform gracefully. A page transforms gracefully when it remains accessible despite any constraints that may include (though not be limited to) physical, sensory, and cognitive disabilities, work constraints, and technological barriers. For example, a web surfer may not be able to see, hear, move, or use a keyboard or mouse, or may have difficulty reading or comprehending text. The surfer may have a small screen, a slow Internet connection, an early version of a browser, a different browser, a voice browser, or a different operating system. By following the guidelines, page authors and site developers can create pages that transform gracefully regardless of the context in which the web page is surfed.
For web pages to transform gracefully, structure must be separate from presentation. Structure refers to the logical organization of a page while presentation refers to how a page is rendered, such as print, computer graphics, text, or synthesized speech.
Web pages transform gracefully when text or text equivalents are provided. Text can be rendered in ways that are available to almost all browsing devices and accessible to almost all users.
Web pages should not rely on one type of hardware and should be usable by people without a mouse, with small screens, low resolution screens, black and white screens, no screens, or with only voice or text output. The theme of graceful transformation is addressed primarily by Guidelines 1 to 11.
Web page authors should make page content understandable and navigable. The language of a web page should be clear and simple, but also provide understandable mechanisms for navigating within and between pages. Providing navigation tools and orientation information in web pages maximizes accessibility and usability. Not all surfers can make use of visual clues such as image maps, proportional scroll bars, side-by-side frames, or graphics that guide sighted users with graphical desktop browsers. Web surfers may also lose contextual information when they can only view a portion of a page, either because they are accessing the page one word at a time as with a speech synthesizer or a Braille display, or one section at a time as with a small or magnified display. Without orientation information, users may not be able to understand very large tables, lists, or menus. The theme of making content understandable and navigable is addressed primarily in Guidelines 12 to 14.
Principles of Accessible Web Design
The WAI has produced an extensive set of guidelines for authoring accessible web pages. Since the Guidelines are a technical document that may be somewhat overwhelming to a beginning web author, the HTML Writers Guild (see www.hwg.org) has proposed six principles of accessible web design upon which the WCAG were written. The following principles are the basic rules for accessible design that formed the specific instances described in each individual entry in the guidelines (Bartlett, 1998):
HTML 4.01 is W3C's recommendation for the latest version of HTML. HTML 4.01 was released on December 24, 1999, and fixes bugs in the HTML 4.0 specification, which for instance, omitted the name attribute on the IMG and FORM elements. HTML 4.01 defines the semantics and data types for HTML. HTML 4.01 includes mechanisms for style sheets, scripting, embedding objects, improved support for right to left and mixed direction text, and enhancements to forms for improved accessibility for people with disabilities. HTML 4.01 is specified according to three variants:
The web author designates which of these variants are used on a web page by inserting a line called a Document Type Definition (DTD) at the beginning of the document. This line is used by the validation service to determine the variant of HTML 4.0 that is used on a page. Each variant has its own DTD. For example, the DTD for a web page that is HTML 4.01 Transitional is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">The complete HTML 4.01 specification is available in English in several formats, including HTML, plain text Postscript, and PDF at http://www.w3.org/TR/1999/REC-html401-19991224.
Cascading style sheets (CSS) facilitate accessibility to web pages by separating document structure from presentation. CSS2 is the current specification for cascading style sheets and is a recommendation of the W3C. A discussion of the accessibility features of CSS2 may be found at www.w3.org:80/TR/CSS-access.
Style sheets were designed to allow precise control over page presentation properties such as character spacing, text alignment, object position on the page, audio and speech output, or font characteristics apart from markup. By separating style from content, web authors can simplify the HTML in their documents while making the documents more accessible at the same time. CSS facilitates accessibility in several ways:
Style sheets are cascading because web page content can be filtered through several layers of style sheets. CSS-compliant browsers allow viewing of a web page through at least three style sheets includes styles embedded in the page by the web author, an external style sheet created by the web page author and loaded with the web pages, a user-defined style sheet, and the default style sheet the browser uses to display pages.
A style sheet minimally should provide declarations for all structural elements used in the HTML source. The following is an example of a source document encoded in HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"This HTML source results in the following document tree:
According to the definition of HTML, HEAD elements will be inferred during parsing and become part of the document tree even if the HEAD tags are not in the document source. Additionally, the parser knows where the P and LIs end, even though there are no </P> and </LI> tags in the source. Therefore, the style sheet for this HTML source minimally should include declarations for the <BODY>, <H1>, <P>, <UL>, and <LI> elements.
To create a web page with CSS, use HTML code with few or no deprecated HTML tags. Deprecated tags are tags that are part of the HTML specification but are expected to be phased out of subsequent versions of HTML. Deprecated tags are HTML elements and attributes that control the way text is displayed. Web pages using CSS essentially need to be unadorned or unformatted (generally just the tags included in the document tree).
It's important for web authors to understand how style sheets work and follow the document tree so that all structural elements are defined in the style sheet.
External style sheet documents can be linked to web pages or styles can be embedded within an HTML document. Style declarations can be embedded at the beginning of an HTML document using a STYLE tag (e.g., <STYLE> </STYLE>) or embedded inside elements in HTML (called inline styles) using a STYLE attribute (e.g., <H1 STYLE="text align: center">Heading Level One</H1>. All methods of style declarations can be used in a single web page.
An example of a style sheet embedded in a web page for the previous document tree might look like this:
<STYLE TYPE="text/css"> <!- -This style sheet identifies the type of medium used for it as a text (TYPE="text/css") in contrast to audio or video. Comments are used to hide the content of the style sheet from older browsers that do not recognize styles. HTML elements embedded inside of other elements will inherit tye styles of the outer element.
A more comprehensive discussion of the use of cascading style sheets is beyond the scope of this tutorial.
Several web-based tools are available to analyze web pages for their conformance to the accessibility guidelines, HTML 4.0, and CSS2.
HTML 4.01. To validate a web page for HTML 4.0, the page must contain a Document Type Definition (DTD) at the beginning of the page. The validation tool knows which variant of HTML 4.01 is being validated based on the DTD. The HTML validator can be accessed at http://validator.w3.org/. The HTML validator provides validation by URL or by uploading HTML into the validator. Web authors can validate the HTML used in the web pages for conformancy with the HTML 4.01 recommendation, and web pages that validate can display a logo to identify the conformance claim.
CSS2. A validator for CSS2 can be downloaded from http://jigsaw.w3.org/css-validator/ or validated by URL, by entering CSS text into the validator, or by uploading CSS text into the validator. Validating style sheets requires the use of valid HTML. Web authors can validate the style sheets used in the web pages for conformancy and style sheets that validate can display a logo to identify the conformance claim.
The following web authoring tips provide a quick guide for establishing WAI Level A conformity (see checklist at www.w3.org/TR/1999/WAI-WEBCONTENT-19990324/full-checklist.htmland). A more comprehensive discussion of techniques that implement the checkpoints is defined in the WCAG at www.w3.org/TR/WAI-EBCONTENT-TECHS/.
The W3C has developed and published a downloadable Curriculum for Web Content Accessibility Guidelines 1.0 slide set at http://www.starlingweb.com/wai/wcag/ . Several of the following examples are provided in the example set of this curriculum at http://www.starlingweb.com/wai/wcag/oversam.htm (Chuck Letourneau & Geoff Freed, Copyright (c) 2000 W3C).
a. Provide redundant text links for each active region of a server-side image map.
EXAMPLE:
Server-side image maps (those using the ISMAP attribute in the IMG element)
usually do not provide any textual information about the links that are coded
into them. If a server-side image map has hyperlinks to several sections of
the site, then provide a text alternative on the page. For example, the HTML
code:
produces the following server-side image map and text equivalent:
[ Goals | System Components | Training Calendar |
Best Practices | Resource Center | Staff | Newsletter ]
The ALT text in the IMG element informs users that a text equivalent exists -- but does not describe the image itself. To describe the image map in detail, use LONGDESC.
b. Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
c. When using image maps, use the ALT tag for each image and image map link and provide a text version of the links of an image map elsewhere on the web page.
EXAMPLE:
When using client-side image maps, it may not be enough to provide ALT text
to describe the destination of the link in the AREA element that creates the
geometric hot-spots on an image map. To ensure everyone can navigate your site,
it is still important to provide redundant text links. For a client-side image
map describe the destination that each active area will link to. For example,
the HTML code:
produces the following client-side image map and text equivalent:
[ Goals | System Components | Training Calendar |
Best Practices | Resource Center | Staff | Newsletter ]
d. Bitmapped text images cannot be read by a screen reader and should also use the ALT tag.
EXAMPLE:
For an image that is simply a bit-map of text (because you want to use special
graphical font-effects or other transformations that would be difficult or impossible
using style sheets), provide the text equivalent, e.g.<IMG SRC="wai-lg.gif"
ALT="Graphical Link to Web Accessibility Initiative">
e. Images or buttons with links should be large enough to allow surfers who use an alternate type of pointing device with their computer to easily select the image.
EXAMPLE:
The following image is sufficiently large to allow surfers with alternative
pointing devices to easily select the image:
a. Use tables primarily to convey statistical data or organized information. For data tables that have two or more logical levels of row or column headers, use markup to indicate data cells and header cells.
EXAMPLE:
If there is a legitimate need to present data in a tabular format, then use
the HTML TABLE element and its supporting elements and attributes (e.g., TR,
TD, TH and CAPTION) instead of the PRE tag for preformatted text or style sheets,
which makes tabular data more difficult to understand for users of assistive
technology.
A simple data table created with proper data table markup, might look like this:
| Column 1 Header | Column 2 Header | |
|---|---|---|
| Row 1 Header |
R1C1 Data
|
R1C2 Data
|
| Row 2 Header |
R2C1 Data
|
R2C2 Data
|
The table is created using the following HTML code:
<TABLE BORDER=1>b. Restrict the use of tables for layout of web pages. Use Cascading Style Sheets to layout and format text and images on a web page instead of tables. If a table is used for formatting text, use the SUMMARY tag.
HTML EXAMPLE:
<TABLE width="640" border="0" CELLSPACING="0" CELLPADDING="4" SUMMARY="This table is for formatting purposes only.">c. If tables are used for formatting and placement, test them in a text-only browser such as Lynx to verify that a text-only browser will display your content properly or with a browser reader to determine that the layout of your web page is comprehensible to users of assistive technology.
a. Title each frame in a web page to facilitate frame identification and navigation.
HTML EXAMPLE:
<FRAME SRC="tocleft.html" TITLE="Table of Contents Frame">
b. If possible, do not use frames in a web page because frames cause difficulty in printing, viewing, and navigation for all users, not just those with physical disabilities.
a. Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.
b. If pages are not usable when turning off applets and scripts, provide equivalent information on an alternative accessible page.
a. Provide an associated auditory description or text transcript and provide a link to the text transcript for the important information of a multimedia presentation.
b. Synchronize captions or auditory descriptions of the visual track for any time-based multimedia presentation with the presentation.
At present there are three formats or languages that support the ability to synchronize equivalent alternatives. These are Apple's QuickTime, the W3C's SMIL (Synchronized Multimedia Integration Language) and Microsoft's SAMI (Synchronized Accessible Multimedia Interchange). In order to view the accessible multimedia presentations, download the appropriate software for one of these formats.
QuickTime
MoviePlayer, which is part of QuickTime 4.0, is necessary to show accessible QuickTime movie clips using either a Macintosh or PC. A free version can be downloaded for either platform or Quicktime 4.0 Pro can be downloaded for a small licensing fee.
SMIL
Different SMIL players are available. The G2 Player from RealNetworks will show accessible movie clips on a PC (no Mac version is available yet).
SAMI
Microsoft's SAMI format is now available for use, but authoring tools are still being developed. SAMI format can be used with Microsoft Media Player on your PC (no Mac version is available yet). More information about SAMI is available at Microsoft's SAMI information page at http://www.microsoft.com/enable/sami/.
c. Interactive content that requires the surfer to press a key should not be time-limited and animations that use text should show the text long enough for a slow reader to read it.
a. If it is not possible to create an accessible page, provide a link to an alternative page that uses W3C accessibility technologies, has equivalent information and functionality, and is updated as often as the original page.
EXAMPLE:
This option is not generally feasible because of the difficulty in keeping alternative pages up to date with the full content of the original page. Alternative pages should be provided only after all other pertinent techniques outlined in the Web Content Accessibility Guidelines have been attempted (unless the alternative page is automatically generated from the same source as the original page).
Here is one common way to give surfers a choice:
Welcome to the Web Accessibility Page!
<A HREF="textversionpath/">For a text version of this site, follow this link.</A>b. Provide an alternative to web form submission such as phone number, fax number, e-mail address, or postal mail address to submit information. Even though a form may be accessible, there may be other ways of filling it out without using the web that are more convenient and less time-consuming for the surfer with disabilities.
a. Use adequate contrast between text and background colors as well as colors used in graphics. Dark text against a light background provides the most contrast for people with low vision.
EXAMPLE:
Do not use color to convey information unless the information is also clear from the markup and/or content of the displayed text. The web page on the left contains dark text on a light background, which is good contrast for viewing in almost any circumstance. The web page on the right uses multiple colors to convey information and demonstrates poor choices for foreground and background color. Some people or some devices might not easily interpret the content.
|
Web Accessibility Design Features
|
Web Accessibility Design Features
|
b. Avoid using busy patterns or brightly colored background images. Do not tile an image as a background that will distract from the text or make it difficult to distinguish between the background and foreground elements.
c. Make sure your web pages can be viewed on a monochrome or grayscale monitor. A web page that can be viewed in grayscale or monochrome can also be printed without loss of information.
a. Use text for links that make sense when read out of context. For example, a link that says "Click Here" has no meaning out of context. Link text should be descriptive, yet not too long, for it may cause difficulty for screen-enlarging software.
EXAMPLE:
HTML code like this:
displays like this on a web page:
Follow this link to the Web Accessibility Page.
While HTML code like this:
To go to the Web Accessibility Page,
<A HREF="access.html">click here.</A>displays like this on a web page:
To go to the Web Accessibility Page, click here.
b. Insert printable, non-link characters between links that are adjacent, such as an asterisk (*) or a vertical line (|). Visually impaired users and screen readers may have difficulty distinguishing between links that are separated only by a space.
EXAMPLE:
To display text links like this:
[ Goals | Components | Training Calendar | Best Practices | Resource Center | Staff | Newsletter ]
use HTML code like this:
[<A HREF="html/goals.html">Goals</A>Validation of accessibility is a continuous process. Validation of accessibility should be performed with both automatic tools and manual examination. Validation procedures should be used at the earliest stages of web page development where accessibility issues are easier to identify, correct, or avoid. To assist in web page design and validation, the W3C provides a Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist.html . A table containing a checklist with the Priority 1 Guidelines is provided in Appendix A at the end of this workbook.
When developing web pages, the following validation methods will facilitate the development of accessible web pages that conform to the WCAG:
Bartlett, K. (1998). Six Principles of Accessible Web Design: An Introduction to the WAI Page Author Guidelines. HTML Writers Guild, Inc. [Online]. Available: <http://www.hwg.org/resources/accessibility/sixprinciples.html>
Bartlett, K. (1999). Web accessibility and users with disabilities. HTML Writers Guild, Inc. [Online]. Available: <http://www.hwg.org/why/essay_kb_01.html>
Casey, C. (September, 1999). Accessibility and the educational web site. Syllabus, 13(2), 26-30.
Kaye, H.S. (2000). Computer and Internet use among people with disabilities. San Francisco, CA: Disability Statistics Center, Institute for Health and Aging, University of California.
National Council on Disability. (September, 1997). NCD Bulletin. (Available from the National Council on Disability, 1331 F. Street, NW, Suite 1050, Washington, D.C. 20004-1107).
| Checkpoint | Yes | No | N/A | |
In General |
||||
| Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. |
1.1 |
|||
| Ensure that all information conveyed with color is also available without color, for example from context or markup. | 2.1 | |||
| Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). | 4.1 | |||
| Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. | 6.1 | |||
| Ensure that equivalents for dynamic content are updated when the dynamic content changes. | 6.2 | |||
| Until user agents allow users to control flickering, avoid causing the screen to flicker. | 7.1 | |||
| Use the clearest and simplest language appropriate for a site's content. | 14.1 | |||
And if you use images and image maps |
||||
| Provide redundant text links for each active region of a server-side image map. |
1.2 | |||
| Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. | 9.1 | |||
And if you use tables |
||||
| For data tables, identify row and column headers. | 5.1 | |||
| For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. | 5.2 | |||
And if you use frames |
||||
| Title each frame to facilitate frame identification and navigation. | 12.1 | |||
And if you use applets and scripts |
||||
| Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. | 6.3 | |||
And if you use multimedia |
||||
| Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. | 1.3 | |||
| For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. | 1.4 | |||
And if all else fails |
||||
| If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. | 11.4 | |||
http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10-chktable.html
All Thing Web: http://www.pantos.org/atw The primary focus of All Things Web is to help web designers and authors create usable web pages.
AWARE Center: http://aware.hwg.org/ Accessible Web Authoring Resources and Education is a part of the HTML Writer's Guild and serves as a central resource for web authors for learning about web accessibility.
HTML Writer's Guild: http://www.hwg.org/ The HTML Writer's Guild is the largest international organization of web authors.
Microsoft Accessibility Home Page: http://www.microsoft.com/enable/ Microsoft's web site for accessibility technology issues and resources.
National Center for Accessible Media: http://www.wgbh.org/wgbh/pages/ncam A research and development facility that works to make media accessible to underserved populations such as persons with disabilities, minority-language users, and people with low literacy skills.
TRACE Center: http://www.tracecenter.org/world/ The Trace Center is currently working on ways to make standard information technologies and telecommunications systems more accessible and usable by people with disabilities. This work is primarily funded by the National Institute on Disability and Rehabilitation Research (NIDRR) of the U.S. Department of Education.
Web Accessibility Initiative Curriculum: http://www.starlingweb.com/wai/wcag/ On-line curriculum for teaching the Web Content Accessibility Guidelines.
Home Page Reader http://www.austin.ibm.com/sns/hpr.html Home Page Reader from IBM is a spoken on-ramp to the Internet for computer users who are blind or visually impaired.
PwWebSpeak Plus http://www.prodworks.com/issound/catalog/catalog_pwwebspeak.html On-visual Web browser that provides you efficient and direct auditory access to Web pages and the resources of the Internet. pwWebSpeak by isSound understands HTML, the language of the Web, and lets you navigate and browse through the pages by reading them back to you under your control.