print header

Web Accessibility Standards

Preface

In an effort to address the need for accessible Web sites, UW-Eau Claire has established these Web Accessibility Standards for the development of Web sites, intranets, and Web-based applications.

These standards, written by the EIT Accessibility Committee members and other interested persons, are based on Federal "Section 508" and World Wide Web Consortium accessibility guidelines. Why create an additional set of standards when the Section 508 and W3C standards already exist? Section 508 is very general and W3C is very complex and provides standards which go beyond what current technology allows us to effectively do. These standards not only meet all current requirements but also meet those additional needs we determined were important for the users of this campus. These standards are also devised to be easier to read, understand and implement.

Contents:

Introduction

Purpose

The UW-Eau Claire Web Accessibility Standards are designed to provide practical and specific guidance for the development of Web sites, intranets, and Web-based applications that are accessible to all individuals, including those with disabilities.

Audience

These standards are intended for use by all Web authors, developers, and content contributors creating or maintaining Web pages for UW-Eau Claire. It is also meant to be a standard by which to base considerations for the purchase or development of Web-based applications. The basic concepts should be understandable by anyone familiar with Web technologies. Knowledge of Hypertext Markup Language (HTML) and related Web languages will help in fully understanding the Implementation Guidelines.

Scope

While it is the goal to have all pages in all sites completely accessible, it is not practical to expect this to occur immediately. We expect this to take place over a period of time. However, one cannot indefinitely postpone compliance. Please use the following guidelines when considering how to comply with UW-Eau Claire's Web accessibility policy.

  • All new pages created after the adoption of this policy must be made accessible
  • All pages that existed prior to the adoption of this policy must be evaluated to determine whether they meet these standards. If not, the site will be updated as soon as practical. A good time to do this is during a site redesign
  • When decisions about the use of scarce resources to modify pages are being made, use the following common sense approach:
    • Modify the following types of pages as soon as possible if not immediately
      • Official, time-sensitive, related to current courses taught, much used (popular) pages
    • Modify the following types of pages as soon as practical
      • Resource information, occasional use, not currently used in the classroom
    • Do not modify, but indicate that if there are problems, the pages will be provided in an accessible format upon request
      • Archival/historical information, pages soon to be removed
    • Remove pages that are no longer needed

Be aware that there may be easy ways to correct the majority of accessibility issues on pages. Ask advice if you are not sure.

Relation to Existing Accessibility Standards

The UW-Eau Claire Web Accessibility Standards are based on two sets of existing standards:

The UW-Eau Cliare Web Accessibility Standards are designed to meet or exceed all Federal Section 508 requirements and all WCAG "Priority 1" Checkpoints. These standards exceed the minimum requirements in many areas, incorporating a number of WCAG "Priority 2" and "Priority 3" Checkpoints determined through testing. Each Guideline in these standards includes a reference to the corresponding Section 508 requirements and WCAG Checkpoints.

Performance Criteria

Both Performance Criteria and Implementation Guidelines are necessarily technology-dependent and will be updated as technologies evolve and change. The Web technologies considered the current standards as of this version include:

  • Hypertext Markup Language (HTML) 4.01
  • Extensible Hypertext Markup Language (XHTML) 1.0
  • Cascading Style Sheet (CSS) Level 1 & 2
  • Document Object Model (DOM) Level 1
  • Synchronized Multimedia Integration Language (SMIL) 1.0
  • JavaScript & Dynamic HTML (DHTML)

Note: The use of other technologies (e.g., Java, Flash) and other document formats (e.g., Adobe Acrobat PDF, Microsoft Word, WordPerfect) is permissible if used in accordance with the standards outlined in this document. See the sections on Applets and Plug-ins and Downloadable Documents for more information.

Individuals with disabilities use a variety of accessibility techniques and assistive technologies to access Web-based information. From a practical standpoint, Web sites must therefore be compliant and compatible with these accessibility tools in order to be accessible to people with disabilities. From this perspective, the following functional performance criteria can be used to judge whether accessibility is effectively achieved:

UW-Eau Claire Web Accessibility Performance Criteria

All information and functionality presented in a Web site, intranet, or Web-based application shall be available in a manner that is:

  • Compliant with browser and system font size and color settings
  • Completely operable using keyboard only
  • Completely operable using leading screen magnification software
  • Completely operable using leading screen reading software
  • Completely operable using leading speech recognition software
  • Completely understandable without sound
  • Completely understandable without color
  • Clear and consistent
  • Unlikely to trigger photosensitive seizures

Implementation Guidelines

These are the detailed techniques for addressing accessibility using current Web technologies.

1. Coding

1.1 - Use valid, standard Web programming code.     >Contents

What:
The World Wide Web Consortium (W3C) sets and publishes standards for most Web programming languages, including HTML 4.01, XHTML 1.0, CSS Level 1 & 2, DOM, and SMIL. Programming code is considered "valid" when it follows all the rules and conventions specified in the published standards.

Why:
Screen readers and other assistive technologies can more accurately interpret and interact with Web pages that are built using valid, standard code. W3C languages are designed with accessibility in mind.

How:
Indicate the programming language you are using by starting your code with a document type declaration such as:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Use the W3C HTML Validation Service (http://validator.w3.org) and W3C CSS Validation Service (http://jigsaw.w3.org/css-validator) to check your code. Refer to the World Wide Web Consortium site (http://www.w3.org) for full specifications and documentation.

Ref:
WCAG 3.2 (P2), 11.1 (P2)

1.2 - Use appropriate markup to convey document structure.     > Contents

What:
HTML includes markup (programming code) to identify the structural elements of a document. For example, the <p> element identifies a paragraph and <h1> identifies a first-level heading.

Why:
Screen readers use structural elements to help make reading more efficient. For example, some screen readers can skip from heading to heading to allow the user to "skim" the document.

How:
Identify section heading, paragraphs, lists, quotes, etc using the appropriate tags instead of relying on formatting commands to distinguish these elements. For example, use <h1> tags to identify top-level headings rather than simply applying font-size or bold formatting commands. Do not misuse structural elements for formatting effects, such as using <h1> to make text bold or <blockquote> to indent a paragraph that is not actually a quotation.

Ref:
WCAG 3.5, 3.6, 3.7, 5.4 (P2)

1.3 - Use style sheets for content formatting whenever possible.     > Contents

What:
Cascading Style Sheets (CSS) is a formatting language designed to compliment HTML. While HTML is designed to identify a document's structure, CSS is intended for formatting and presentation.

Why:
In general, users can most easily override formatting settings made using CSS. The use of CSS for formatting also tends to facilitate the proper use of HTML to identify document structure.

How:
See the W3C's Cascading Style Sheets site (http://www.w3.org/Style/CSS/) for specifications, tutorials, and resources.
Note: Some older Web browsers, notably Internet Explorer 3 and Netscape 4, have problematic support for CSS. Be sure to test pages using CSS in multiple browsers.
Ref:
WCAG 3.3 (P2)

2. Text

2.1 - Avoid using images to display text.     > Contents

What:
Web developers often use images of text to achieve a specific style, size, or special effect.

Why:
Users with limited vision rely on the ability to enlarge text or choose enhanced color combinations. While, most Web browsers cannot change the size and color of images, newer browsers and screen magnifiers are beginning to provide this capability. But since using images as text also impedes ability to index for search engines, ability to easily change content and other abilities, it is still best to avoid.

How:
Whenever possible, use actual text instead of images of text. Style sheets can be used to achieve specific sizes, colors, or effects. Text that requires exact formatting, such as logos, are appropriate exceptions.

Ref:
WCAG 3.1 (P2)

2.2 - Specify the language of text.     > Contents

What:
HTML uses the lang attribute to specify language in a Web page. It can be set for any HTML element.

Why:
Words written in foreign languages can be unintelligible when spoken by a screen reader. Some screen readers are able to pronounce words in their appropriate language if it is specified.

How:
Use the lang attribute on the <html> element to identify the primary language of each document, for example, <html lang="en">, for English.
Use the lang attribute on <span> or other elements to identify words or phrases in other languages. For example, a Spanish phrase within an English document could be coded as <span lang="sp">se habla español</span>.
Note: Not all screen readers support automatic language changes, but setting the lang attribute will not negatively affect those that do not.

Ref:
WCAG 4.1(P1), 4.3 (P3)

2.3 - Avoid using "ASCII art."     > Contents

What:
"ASCII art" (and "emoticons") are images created using special arrangements of text characters and symbols. For example, ":-)" is often used to create a smiley face, and "->" is often used as an arrow.

Why:
Screen readers read most ASCII art literally, which can be extremely confusing. For example, ":-)" reads as "colon dash right parenthesis," and "->" as "dash greater than."

How:
Use images with appropriate alternate text instead of ASCII art.

Ref:
WCAG 1.1 (P1)

3. Colors

3.1 - Do not convey information with color alone.     > Contents

What:
Color is often used to indicate special functions or status. For example, required form fields are frequently indicated with red labels.

Why:
Users with blindness, limited vision, or color-blindness may miss information presented with color.

How:
Whenever color is used as an indicator, use a non-color-based indicator as well. For example, required form fields could be identified with asterisks as well as color.

Ref:
WCAG 2.1 (P1); 508 c

3.2 - Use contrasting foreground and background colors.     > Contents

What:
Web authors can set specific colors to be used for foregrounds (text) and backgrounds. Sometimes images are used as backgrounds.

Why:
Users with limited vision or color-blindness may have difficulty reading text that is similar in color to its background.

How:
For text, use dark colors on light backgrounds, or vice versa. Avoid combinations of red and green as well as busy background images.

Ref:
WCAG 2.2 (P2)

4. Images

4.1 - Provide "alternate text" for all images.     > Contents

What:
The HTML image element (<img>) includes an "alternate text" attribute (alt) that is used to provide text that can be substituted when the image itself cannot be displayed. Alternate text is meant to be a concise replacement for an image and should serve the same purpose and convey the same meaning.

Why:
Individuals who are blind or have low vision cannot perceive information presented in images; screen reading software reads alternate text instead.

How:
ALL images must have appropriate alternate text. As a rule of thumb, consider what you might say if you were reading the Web page to someone over the telephone. You do not need to include the words "image of" or "graphic of."
Specifically:
  • For images that contain words or letters - use alternate text that includes the same words or letters.
  • For images links - use alternate text that identifies the link's destination or function. You do not need to include the words "link to."
  • For images that are invisible, purely decorative, or otherwise do not convey meaning - use alt="" (null) to indicate that the image can be safely ignored by a screen reader.
Ref:
WCAG 1.1(P1); 508 a

4.2 - Provide full descriptions for graphs, diagrams, and other meaningful images.     > Contents

What:
"Meaningful" images are images that convey more information than can appropriately be expressed as alternate text.

Why:
A full description allows a user who cannot see or understand a meaningful image to receive the same information as a sighted individual.

How:
Present a full description of a meaningful image either on the page on which the image appears or through a link immediately preceding or following the image. Use alternate text to provide a concise name for the image. For example, the alternate text of a graph should state its title and the long description should summarize its trends and/or present a table of its data.
Note: The longdesc attribute of the <img> element can also be used to provide a link to a full description. Because longdesc it is not yet supported by most Web browsers, it should not be used as the only method of providing a full description.

Ref:
WCAG 1.1 (P1); 508 a

5. Image Maps

5.1 - Provide alternate text for each area in client-side image maps.     > Contents

What:
Image maps are images divided into multiple "areas," with each area having its own hypertext link.

Why:
Just as images must have alternate text, each area of an image map must also have appropriate alternate text for use when the image is not displayed.

How:
Use alternate text that indicates the function or destination of the link for each area of a client-side image map. The image itself should have alternate text that indicates the overall function of the image map.

Ref:
WCAG 1.1(P1); 508 a

5.2 - Avoid using server-side image maps.     > Contents

What:
While client-side image maps and server-side image maps look and operate similarly, they are technically very different. Because of the way server-side image maps work, all information about the image and links is stored at the Web server and is not available to the user's Web browser or assistive technology.

Why:
Screen readers cannot identify or read the separate areas or links within server-side image maps.

How:
Whenever possible, use client-side image maps instead of server-side image maps. If server-side image maps must be used, provide a set of text links that duplicate all the functions/destinations included in the image map.

Ref:
WCAG 1.2, 9.1(P1); 508 e, f

6. Audio

6.1 - Do not convey information with sound alone.     > Contents

What:
It is possible to use sound for a variety of purposes, including presenting warning signals, cues, or verbal instructions.
Why:
Users who are deaf or hard of hearing may miss information provided only through sound.
How:
Whenever significant information is provided by sound, include a visual indicator that provides the same information as well.

Ref:
WCAG 1.1(P1); 508 a

6.2 - Provide text transcripts for audio containing speech.     > Contents

What:
"Audio containing speech" includes audio recordings or live broadcasts of speeches, seminars, conferences, etc. A text transcript is a word-for-word written record of the spoken content of such an event.

Why:
Individuals who are deaf or hard of hearing may require text transcripts to access audio information.

How:
Provide a link to a text (or HTML) transcript of any audio presented on a Web site. Transcripts should be posted at the same time the audio is made available. Computer-Aided Real Time (CART) captioners can transcribe live events.

Ref:
WCAG 1.1 (P1); 508 a

7. Multimedia

7.1 - Provide synchronized captions for multimedia containing speech.     > Contents

What:
Multimedia generally refers to recorded or live media containing both video and audio tracks. Captioning (as in "closed captioned") is essentially a text transcript of the audio synchronized with the audio/video tracks of the presentation.

Why:
Individuals who are deaf or hard of hearing may require captions to access the audio information in multimedia.

How:
Whenever possible, captions should be implemented using Synchronized Multimedia Integration Language (SMIL) to synchronize the display of text from a transcript with the video. As a less desirable alternative, captions can be added to a standard video recording and then converted to a Web format.

Ref:
WCAG 1.4 (P1), 508 b

7.2 - Provide audio descriptions for multimedia with significant video.     > Contents

What:
Audio descriptions are verbal descriptions of the actions and images displayed in a video that are inserted during pauses in the regular dialog or audio track. Audio descriptions are only necessary if significant information that is presented visually is not discernable from the dialog or audio track.

Why:
Individuals who are blind or low-vision may require audio descriptions to access the visual information in multimedia.

How:
Carefully consider whether audio descriptions are necessary to present the significant information of a multimedia recording. Many speech-intensive events, such as speeches, lectures, or conferences, may not need audio description.

Ref:
WCAG 1.3 (P1)

8. Animation

8.1 - Avoid flickering, blinking, and unnecessary animation.     > Contents

What:
Animated graphics, Flash, Java, <blink> tags, <marquee> tags, and other techniques are often used to create a variety of animated effects.

Why:
Flickering or blinking between 2 and 55 Hz (flashes per second) can trigger epileptic seizures. Animation can be distracting to users with certain visual or perceptual disabilities.

How:
Do not cause elements to blink regularly between 2 and 55 Hz. Use this general guideline: If an animation has an appearance of a strobe light, or something close, do not use it. Avoid animation and movement unless it provides significant additional information.

Ref:
WCAG 7.1 (P1), 7.2, 7.3 (P2); 508 j

9.1 - Make sure that links are understandable out of context.     > Contents

What:
A link is understandable out of context when it clearly indicates its destination or function without requiring additional information.

Why:
Screen reader users often tab through links (skip from link to link by pressing the Tab key) in order to "scan" a page. Most screen readers also offer a "links list" feature to help speed the process of navigating to specific links. Links that are not understandable out of context, such as "click here" or "more," make these techniques much less efficient.

How:
Use link text that is clear and unambiguous. Avoid using "click here."

Ref:
WCAG 13.1 (P2)

9.2 - Provide a means of skipping past repetitive navigation links.     > Contents

What:
Navigation links are the lists or "menus" of links to all the sections of a site that are often repeated on every page.

Why:
Because navigation links are typically placed at the beginning (top left) of pages, screen reader users must read through all the navigation links before reaching the main area of the page. Individuals who use a keyboard instead of a mouse similarly must tab through all the navigation links before reaching the main area of the page. Providing a means of skipping these links can significantly improve efficiency and usability for screen reader and keyboard users.

How:
Provide a link at the beginning of navigation lists that points to a target at the beginning of the main content area of the page. This link must be visible to screen reader and keyboard users, but can be hidden from other users. It is also acceptable to design a page so that navigation links come at the end of the document.

Ref:
508 o

9.3 - Avoid using small images or text as links.     > Contents

What:
The size of the "clickable" area of a link is limited to the size of the image or text that makes up the link.

Why:
Mouse-users with limited fine motor skills may have difficulty pointing to and clicking on links that are small, especially if the links are close together.

How:
Make sure that images used for links are reasonably large, preferably 32 pixels by 16 pixels or larger. Use standard or enlarged font sizes for text links, and avoid using text links that are shorter than four characters in length. Additionally, avoid placing small links close together.

Ref:
n/a

10. Forms

10.1 - Associate labels with all form fields.     &g