Web Accessibility Standards and Guidelines

Virginia Tech Web Accessibility Standards and Guidelines

Booklet Version: 2007-001

Why standards are important.
Standards and guidelines explain the what, why, and how of making web content accessible. Web content comprised of text, images, sound, video, and other media includes markup languages or code to define structure, presentation, and alternatives for people with disabilities. Accessibility standards and guidelines are documented as follows:

  • What: A statement of the access issue to be addressed by the standard and guideline
  • Why: Explanation as to why the accessibility issue is important
  • How: A short statement of how access can be successfully achieved
  • Known Issues: Any known concerns not fully addressed by the standard and guideline
  • AccessVT: guideline reference
    WCAG 1.0 guideline reference(s) when applicable
    Section 508 standard reference(s) when applicable

Standards and Guidelines and Access Performance Criteria

These include:

  1. Standards and Guidelines - the procedures that will implement university access policies for web accessibility. These procedures require the use of development and maintenance tools and techniques that validate markup language (coding) and evaluate website accessibility throughout the lifetime of the website or web-based application.
  2. Access Performance Criteria - a concise list of functional goals that must be achieved for a website or web-based application to be considered accessible.

Individuals with disabilities use a variety of abilities, access techniques, and assistive technologies to utilize web-based information. From a practical standpoint, accessible websites must therefore be compliant with accessibility standards and guidelines, as well as being compatible with adaptive or assistive technologies. From this perspective, the following functional performance criteria can be used to judge whether accessibility is effectively achieved.

All information and functionality presented in a website or web-based applications shall be available in a manner that is:

  • Compliant with university supported browsers
  • Completely operable with system font sizes and colors set by the user
  • Completely operable using a keyboard only
  • Completely operable using leading screen magnification software
  • Completely operable using leading screen or synthesized speech reading software
  • Completely operable using leading speech recognition software
  • Completely understandable without sound
  • Completely understandable without color
  • Clearly and consistently navigable
  • Unlikely to trigger photosensitive seizures

External References based on Virginia Tech Access Policies

Standards and Guidelines and Access Performance Criteria are user based and technology dependent and will be updated as user needs and technologies evolve and change. The web technologies that are considered relevant for the current standards and guidelines are aligned with external references that include:

Virginia Tech web accessibility standards and guidelines are designed to comply with the Americans with Disabilities Act (ADA) and Federal Section 508 requirements of the Rehabilitation Act of 1973. Virginia Tech meets and/or exceeds the minimum requirements of WCAG version 1.0 Level "A" conformance by incorporating most "Priority 1" checkpoints and a number of WCAG "Priority 2" and "Priority 3" checkpoints. AccessVT guidelines are also cross-referenced to WCAG 1.0 guidelines and Section 508 standards that have comparable accessibility objectives.

Format of Web Accessibility Standards and Guidelines

Virginia Tech web accessibility standards and guidelines are formatted in two versions. Both versions are printable:

  • Default Version is organized for reading and printing by section.
    Navigation is by Table of Contents, Quick Reference, and the use of previous or next section arrows. The default version permits you to focus on and print one section of the university guidelines at a time. Future editions will have interactive training materials.
  • Booklet Version is organized for reading and printing as one document.
    Navigation is by Table of Contents, Quick Reference, and by Go to Table of Contents links. The booklet version can be read sequentially (top-to-bottom) by scrolling or by use of the Go to Table of Contents link at the end of each section. The booklet version can be printed in its entirety.

Navigational note: The use of hypertext links in the Table of Contents and Quick Reference sections will navigate only within their respective versions, default or booklet, unless specified otherwise.


Table of Contents

  • 1. Coding

    • 1.1 - Use valid, standard web programming code.
    • 1.2 - Use the correct DOCTYPE declaration at the top of each page.
    • 1.3 - Use appropriate markup to convey document structure.
    • 1.4 - Use style sheets for formatting whenever possible

  • 2. Text

    • 2.1 - Avoid using images to display text.
    • 2.2 - Avoid using absolute sizes for fonts.
    • 2.3 - Specify the language attribute for all text.
    • 2.4 - Avoid using "ASCII art."

  • 3. Colors

    • 3.1 - Do not convey information with color alone.
    • 3.2 - Use contrasting foreground and background colors.

  • 4. Images

    • 4.1 - Provide "alternate text" for all images.
    • 4.2 - Provide full descriptions for graphs, diagrams, and other meaningful images.

  • 5. Image Maps

    • 5.1 - Provide alternate text for each area in client-side image maps.
    • 5.2 - Avoid using server-side image maps.

  • 6. Audio

    • 6.1 - Do not convey information with sound alone.
    • 6.2 - Provide text transcripts for audio containing speech.

  • 7. Multimedia

    • 7.1 - Provide synchronized captions for multimedia containing speech.
    • 7.2 - Provide audio descriptions for multimedia with significant video.

  • 8. Animation

    • 8.1 - Avoid flickering, blinking, and unnecessary animation.
    • 8.2 - Avoid uncontrolled animation and/or loop elements.

  • 9. Links

    • 9.1 - Make sure that links are understandable out of context.
    • 9.2 - Provide a means of skipping past repetitive navigation links.
    • 9.3 - Avoid using small images and text as links.

  • 10. Forms

    • 10.1 - Associate labels with all form fields.
    • 10.2 - Position labels as close as possible to form fields.
    • 10.3 - Include any special instructions within field labels.
    • 10.4 - Make sure that form fields are in a logical tab order.

  • 11. Data Tables

    • 11.1 - For simple data tables, explicitly identify headings for all columns and rows.
    • 11.2 - Avoid using complex data tables.

  • 12. Frames

    • 12.1 - Provide meaningful names and page titles for all frames.
    • 12.2 - Avoid using empty or non-essential frames.

  • 13. Scripts

    • 13.1 - Make sure that significant interactions can be performed with both keyboard and mouse.
    • 13.2 - When client-side scripts are used, make sure that essential content and functionality are available and accessible to assistive technologies...

  • 14. Applets and Plug-Ins

    • 14.1 - Use accessible applets or plug-ins whenever possible.
    • 14.2 - Make sure that essential content and functionality are available when an inaccessible applet or plug-in must be used.

  • 15. Downloadable Documents

    • 15.1 - Provide accessible versions of downloadable documents whenever possible.
    • 15.2 - If a downloadable document cannot be provided in an accessible electronic format, provide information on how to request an alternate format.

  • 16. Window Control

    • 16.1 - Notify users of actions that will open a new window.
    • 16.2 - Do not automatically refresh the current page.
    • 16.3 - Notify users of time limits and provide a means to extend time if needed.

  • 17. Page Layout

    • 17.1 - When using tables for layout, make sure that reading order is logical.
    • 17.2 - When using style sheets for layout, make sure that reading order is logical when style sheets are not supported.
    • 17.3 - Minimize the need for horizontal scrolling (by using relative widths).
    • 17.4 - Utilize pages dimensions that are safe for graphics and printing.

  • 18. Page Content

    • 18.1 - Use the clearest and simplest language appropriate for a page's subject matter.

Section: 1. Coding

1.1 - Use valid, standard web programming code.

What:

The World Wide Web is successful because it is based on set of standards that have been agreed upon by a wide variety of stakeholders in academia, government and industry. The World Wide Web Consortium (W3C) is the de facto keeper of many standards-based programming languages, which are the underpinnings of the Web. These coding, markup languages, and standards include HTML 4.01, XHTML 1.0, CSS Level 1 & 2, XML, DOM, and SMIL.

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:

Programming code is considered "valid" when it follows all the rules and conventions specified in the published standards. Coding practices should utilize features of languages that are "officially" part of a specification and supported by the majority of browsers. Also, programs should gracefully handle situations where browsers or user agents do not implement the standards correctly.

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.

Guidelines:

Access VT: Coding 1.1
WCAG 3.2, 11.1


1.2 - Use the correct DOCTYPE declaration at the top of each page.

What:

The DOCTYPE declaration indicates to the web browser the particular language you intend to use within the document, whether it is HTML 4.01 or XHTML 1.0, and the level of adherence to the standard you intend to follow.

Why:

Proper usage of the DOCTYPE declaration can affect the display of the page, the interpretation of style sheets and the ability to validate html and/or xhtml for syntax. Browsers’ modes vary greatly based on DOCTYPE, especially when a DTD does not specify the "Definition" and/or "URL".

How:

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

The W3C maintains a list of valid document type declarations (http://www.w3.org/QA/2002/04/valid-dtd-list.html) for a variety of web language. Use the correct one for the language of your page. Most web development tools will add a DOCTYPE declaration to the top of a new web page when it is created in the editor.

Known Issues: Proper usage of the DOCTYPE declaration can affect the display of the page and the ability to validate html and/or xhtml for syntax. Browsers’ modes vary greatly based on DOCTYPE, especially when a DTD does not specify the “Definition” and/or “URL”.

Guidelines:

Access VT: Coding 1.2
WCAG 3.2, 11.1


1.3 - Use appropriate markup to convey document structure.

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. Use structural elements according to specifications.

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.

Guidelines:

Access VT: Coding 1.3
WCAG 3.5, 3.6, 3.7, 5.4


1.4 - Use style sheets for formatting whenever possible

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:

Use style sheets to control layout and presentation. In addition to university accessibility training, see the W3C's Cascading Style Sheets site (http://www.w3.org/Style/CSS/) for resource information.

Known Issues: Some web browsers have problems supporting CSS features. If CSS features used by a website are unsupported, make sure that web page content is still readable without style sheets. Be sure to test pages using CSS with web browsers and operating systems supported by the university.

Guidelines:

Access VT: Coding 1.4
WCAG 3.3


Go to Table of Contents

Section 2. Text

2.1 - Avoid using images to display text.

What:

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

Why:

Users with limited vision rely on the ability to enlarge text or choose enhanced color combinations. However, most web browsers cannot change the size and color of images.

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.

Guidelines:

Access VT: Text 2.1
WCAG 3.1


2.2 - Avoid using absolute sizes for fonts.

What:

Font sizes can be set using "absolute" or "relative" units of measurement. Absolute units, notably pixels, points, and inches, are based on fixed physical measurements; "relative" units, such as percentages or "small," "medium," or "large," are based on the user’ default font size.

Why:

Users with limited vision often rely on the ability to enlarge text. Most web browsers allow users to easily change the size of text that has been set with relative units (or not set at all). Using absolute font sizes generally makes it much more difficult for users to change text size to meet their needs.

How:

Set font sizes using relative measurements or avoid setting font sizes altogether.

Known Issues: The CSS "em" unit is a truly useful relative measurement; however, some browsers incorrectly interpret the "em" unit. For more information, see Coding 1.4, regarding the known issues of unsupported CSS features.

Guidelines:

Access VT: Text 2.2
WCAG 3.4


2.3 - Specify the language attribute for all text.

What:

HTML uses the "lang" 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>.

Guidelines:

Access VT: Text 2.3
WCAG 4.1, 4.3


2.4 - Avoid using "ASCII art."

What:

"ASCII are" (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:

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

How:

Use images with appropriate alternative text instead of ASCII art.

Guidelines:

Access VT: Text 2.4


Go to Table of Contents

Section: 3. Colors

3.1 - Do not convey information with color alone.

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 for fields could be identified with asterisks as well as color.

Guidelines:

Access VT: Colors 3.1; WCAG 2.1; Section 508 c


3.2 - Use contrasting foreground and background colors.

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. In general, avoid combinations of red and green as well as busy background images. When possible, give users the ability to control contrasting foreground and background colors.

Guidelines:

Access VT: Colors 3.2;
WCAG 2.2


Go to Table of Contents

Section: 4. Images

4.1 - Provide "alternate text" for all images.

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 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

Guidelines:

Access VT: Images 4.1
WCAG 1.1
Section 508 a


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

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 of 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 its data. The "longdesc" attribute of the <img> element can also be used to provide a link to a full description. Because all web browsers do not support "longdesc", it should not be used as the only method of providing a full description.

Guidelines:

Access VT: Images 4.2
WCAG 1.1
Section 508 a

Go to Table of Contents

Section: 5. Image Maps

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

What:

Image maps are images divided into multiple "areas," 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.

Guidelines:

Access VT: Image Maps 5.1
WCAG 1.1
Section 508 a


5.2 - Avoid using server-side image maps.

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 may not be 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.

Guidelines:

Access VT: Image Maps 5.2
WCAG 1.2, 9.1
Section 508 e, f

Go to Table of Contents

Section: 6. Audio

6.1 - Do not convey information with sound alone.

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 (or text) that provides the same information as well.

Guidelines:

Access VT: Audio 6.1
WCAG 1.1
Section 508 a


6.2 - Provide text transcripts for audio containing speech

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 containing speech presented on a website. Transcripts should be posted at the same time the audio is made available for asynchronous content. For synchronous or live events, real-time captioning or sign language interpreting should be made available. For video captioning, see Section: 7.0 Multimedia.

For information requiring real-time captioning or sign language interpreting services, contact disability service providers found at Services for Students with Disabilities and/or ADA Services in Human Resources. If you are unsure which provider to contact, email the ADA Coordinator in Human Resources.

Guidelines:

Access VT: Audio 6.2
WCAG 1.1
Section 508 a

Go to Table of Contents

Section: 7. Multimedia

7.1 - Provide synchronized captions for multimedia containing speech.

What:

Multimedia generally refers to recorded or live media containing both video and audio tracks. Captioning (as in "closed captioned or open 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 my 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.

Guidelines:

Access VT: Multimedia 7.1
WCAG 1.4
Section 508 b


7.2 - Provide audio descriptions for multimedia with significant video.

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.

Guidelines:

Access VT: Multimedia 7.2
WCAG 1.3

Go to Table of Contents

Section: 8. Animation

8.1 - Avoid flickering, blinking, and unnecessary animation.

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 cognitive disabilities.

How:

Do not cause elements to blink regularly between 2 and 55 Hz. Avoid animation and movement unless it provides significant additional information.

Guidelines:

Access VT: 8.1
WCAG 7.1, 7.2, 7.3
Section 508 j


8.2 - Avoid uncontrolled animation and/or loop elements

What:

Animated graphics, Flash, Java, and other techniques used to create animated effects may be uncontrollable by users and/or loop continuously.

Why:

Animation and looped animated effects can be distraction to users with certain visual or cognitive disabilities. Animation looping may also cause a screen reader to refresh and return to the top of the page without user control or notification. Screen readers will leave the current page location and resume reading at the top of the page when animation is uncontrolled, seriously diminishing the user's experience.

How:

Give users control over animation loop elements, such as start, stop, slow, rewind, and fast-forward. For users of screen readers or persons with certain cognitive disabilities, support the user's ability to skip or hide animation and provide equivalent content in an alternative format.

Guidelines:

Access VT: 8.2

Go to Table of Contents

Section: 9. Links

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

What:

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

Why:

Clear and consistent navigational links are important to people with cognitive disabilities or blindness, and will benefit all individuals. 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 navigation 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; for example, avoid using "click here."

Guidelines:

Access VT: Links 9.1
WCAG 13.1


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

What:

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

Why:

Because navigation links are typically place at the beginning (to 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 of 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 the 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.

Guidelines:

Access VT: Links 9.2
Section 508 o


9.3 - Avoid using small images and text as links.

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 control 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 by 16 pixels of 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.

Guidelines:

Access VT: Links 9.3

Go to Table of Contents

Section: 10. Forms

10.1 Associate labels with all form fields.

What:

HTML forms include "fields" such as buttons (<input type="button">), text boxes (<input type="text">), list boxes (<select>), and more. Each field in a form is typically identified by a text label.

Why:

Screen readers cannot always determine which text label belongs to which input field based on positioning alone. The <label> element makes this association clear, especially when the <label for=""> tag is used. The <label> element also enables many browsers to click on text being displayed by a label in order to focus on an input field.

How:

Use the <label for=""> tag to label every form field.

Note: The value contained within a label's for="" attribute corresponds to the form field's id, not its name.

Guidelines:

Access VT: Forms 10.1
WCAG 12.4
Section 508 n


10.2 - Position labels as close as possible to form fields.

What:

Using certain layout techniques, form labels are not always positioned immediately next to their fields.

Why:

When screen magnification software enlarges a web page it also reduces the field of view. If a form field label is positioned far away from its field, it may be impossible for a screen magnifier-user to view both the field and the label at the same time.

How:

Position labels immediately adjacent to fields, preferably in standard locations, such as on the left or above text boxes and list boxes and on the right of checkboxes and radio buttons.

Guidelines:

Access VT: Forms 10.2
WCAG 10.2
Section 508 n


10.3 Include any special instructions within field labels.

What:

Frequently, special instructions are listed after the field to which they apply. In some cases, instructions are even presented in "pop up" text or in the browser's status bar.

Why:

When filling out a form, screen readers typically read only the field's label. Screen magnifiers will focus on the field and its label, and instructions may be out of the field of view.

How:

Special instructions should be given before the form field and within the field label if possible. If instructions are too long to appropriately fit within the label, they should be given in an instructions section in advance of the form.

Guidelines:

Access VT: Forms 10.3
Section 508 n


10.4 Make sure that form fields are in a logical tab order.

What:

Screen reader and keyboard users move between form fields (and links) using the Tab key. The order in which form fields receive focus is called the tab order. By default, the tab order follows the order in which elements appear in a page's HTML code.

Why:

Depending on the design and layout of a page, the tab order may not match the visual (or logical) order of fields on a form. Reading fields out of their intended order can be disorienting for a screen reader or keyboard user.

How:

Make sure that fields appear in the HTML code in the logical order and/or use "tabindex" to set the appropriate order.

Note: The tabindex attribute is supported by Internet Explorer 4.x, Netscape 6.x browsers and higher; and by newer versions of other browsers (Firefox, Safari, Opera, etc.).

Guidelines:

Access VT: Forms 10.4
WCAG 9.4
Section 508 n

Go to Table of Contents

Section: 11. Data Tables

11.1 - For data tables, explicitly identify headings for all columns and rows.

What:

"Data tables" are simply HTML tables used to display data. (On the other hand, "layout tables" are used to lay out columns and sections on a web page. Both data and layout tables use the <table> element, but their functions, and accessibility issues are very different.) "Headers" identify the content of each row and/or column.

Why:

A screen reader can use table headers to provide row and column information while a user explores the data cells within a table.

How:

Use <th> (table header) or <td> (table data) elements with scope="col" (for column headers) or scope="row" (for row headers) to identify cells that contain row and/or column headings.

Guidelines:

Access VT: Data Tables 11.1
WCAG 5.1
Section 508 g


11.2 - Avoid using complex data tables.

What:

Table with multiple layers of headers and "spanned" columns or rows can become very complex.

Why:

Complex data tables can be difficult to navigate and understand using a screen reader. Only the most advanced screen readers can use advanced table markup to provide orientation information

How:

Whenever possible, simplify complex tables by re-arranging or dividing them into separate tables. When a complex table cannot be simplified, use advanced table markup, such as headers, axis, scope, <col>, and <colgroup>, to fully indicate the relationships between data cells and headers.

Note: See W3C's "Tables in HTML Documents" for complete details on how to markup complex tables.

Guidelines:

Access VT: 11.2 Data Tables
WCAG 5.2
Section 508 h

Go to Table of Contents

Section: 12. Frames

12.1 - Provide meaningful names and page titles for all frames.

What:

HTML frames are used to divide web pages into separate areas, each displaying a separate web page. Each frame is identified by a name attribute and each page contained within a frame is identified by its <title> element.

Why:

To navigate pages with frames, users who are blind must be able to identify the different frames and understand the purpose of each frame. Most screen readers identify frames by speaking the name and/or page title of each frame.

How:

Give each frame an understandable name that indicates the frame's function. For example, use name="Navigation" and name="Content" rather than name="nav" and name="right". Set the <title> element of each page contained within a frame to match the name attributes or to identify the current content of that frame.

Note: Traditionally, the "name" attribute is used for programming and should not contain spaces; the title attribute, which can contain spaces, can also be used to set a more descriptive name for each frame; however, this technique is not yet supported by all screen readers.

Guidelines:

Access VT: 12.1 Frames
WCAG 12.1
Section 508 i


12.2 - Avoid using empty or non-essential frames.

What:

Frames are sometimes used inappropriately for formatting and layout. For example, empty frames can be used to create margins around or within a page.

Why:

Screen readers cannot judge whether the content of a frame is significant and must identify every frame for the user. Having to read this extraneous information for non-essential frames can be time consuming and may be confusing.

How:

Use frames sparingly. If a frame is not necessary for page content or other purposes, eliminate it.

Guidelines:

Access VT: Frames 12.2

Go to Table of Contents

Section: 13. Scripts

13.1 - Make sure that significant interactions can be performed with both keyboard and mouse.

What:

Scripting languages, such as JavaScript (ECMAscript), are simple programming languages that can be used within a web browser to automate certain tasks and respond to user actions when the user performs specific actions (events). User events are often triggered by either mouse or keyboard actions. For example, an image can change color when the mouse pointer hovers over it (the onmouseover event).

Why:

Users with physical impairments may be able to use a keyboard, but not the mouse. For example the blind cannot see a mouse pointer on the screen, but generally use a keyboard for all interactions. Scripts that can only be triggered by the mouse are not usable by these individuals.

How:

Whenever using a mouse-only event (onmouseover, onmouseout) to trigger a significant script action, also use the corresponding keyboard event (onfocus, onblur). Also make sure that keyboard events do not unintentionally trigger script actions. For example, keyboard users should be able to use an arrow key to move through choices in a <select> list without triggering each choice (onchange).

Guidelines:

Access VT: Scripts 13.1
WCAG 6.4, 9.2, 9.3


13.2 - When client-side scripts are used, make sure that essential content and functionality are available and accessible to assistive technologies.

What:

Scripts are often used to dynamically show or hide the content that appears on a web page or to perform important functions, such as checking that entries in form fields are appropriate. "Client-side" scripts, such as JavaScript (ECMAscript), are scripts that are run by the user's web browser. Client-side scripts must be supported by and compatible with the user's browser in order to work. ("Server-side" scripts, such as CGI, ASP, JSP, or PHP, run on the web server before the web page ever reaches the user's browser. Server-side scripts do not generally pose additional accessibility problems.)

Why:

Older assistive technologies and web browsers may not support client-side scripting at all. Even current assistive technologies may interact in unexpected ways with content that is displayed using scripts, such as by skipping text that is dynamically displayed or reading text that is dynamically hidden. Users need to be able to access the same essential content and functionality whether scripts are fully, partially, or entirely not supported. It is not safe to assume that users with disabilities will have scripting support turned off.

How:

Whenever scripts are used, it is the responsibility of the developer to thoroughly test using assistive technologies to ensure that all information and functionality is accessible. If there is any doubt, error on the safe side by ensuring that the essential elements of the page do not rely on scripts.

Note: One approach to ensuring accessibility with scripts is to include a back-up method of providing the same information and functionality that does not require scripts. For example, if a client-side script is used to check an entry in a form field, a server-side script could make the same check. Similarly, if scripts are used for "drop-down" menus, the same menu choices could be provided in an appropriate location elsewhere on the current or subsequent page. Scripting features that are purely decorative and do not present any significant information or functionality do not need to be made accessible unless they violate other accessibility guidelines. (For example, Guideline 8.1 - Avoid flickering, blinking, and unnecessary animation.)

Guidelines:

Access VT: Scripts 13.2
WCAG 6.3
Section 508 l

Go to Table of Contents

Section: 14. Applets and Plug-Ins

14.1 - Use accessible applets or plug-ins whenever possible.

What:

"Applets" and "plug-ins" refer to a variety of technologies that are often used to create advanced and/or interactive content within a browser or a web enabled application. These technologies usually require additional software to be downloaded, installed, and run before any content can be viewed or used.

Why:

Applets and plug-ins to be present on a client system must be readily available for installation, accessible, and/or compatible with (university supported) assistive technologies. When using applets and plug-ins that are inaccessible, the essential content and functionality of a website or web-based application must be made available by an equivalent accessible alternative.

How:

Check with the manufacturer and/or developer of the applet or plug-in to determine how the technology is deemed accessible or can be made accessible using assistive technologies. For applets or plug-ins that are accessible, provide users with a link to any special installation instructions and software. When an inaccessible applet or plug-in must be used, refer to VT Guideline 14.2 Making essential content and functionality accessible when advanced technologies are used.

Guidelines:

Access VT: Applets and Plug-Ins 14.1
WCAG 8.1
Section 508 m


14.2 - Make essential content and functionality accessible when advanced technologies are used.

What:

New web-based technologies are often used to create advanced and/or interactive content within a browser or web enabled application. The more common technologies may include Java applets, Flash content, Podcasts, and/or video streaming.

Why:

Although new technologies may improve the accessibility or usability of the web for some individuals (with and without disabilities); these same technologies are also inaccessible to other individuals due to differences in sensory abilities, physical and memory issues, and learning styles.

How:

When new technologies must be used and are important for a website or application then evaluate the accessibility of the content and functionality. Be sure to consider whether an inaccessible version is actually necessary. If after best efforts the advanced technologies cannot be made accessible, then the essential content and functionality must be made available by an equivalent accessible alternative. Make sure that alternative information and functionality is updated as often as the original website and that links to alternative web content are prominently displayed for all users.

For equivalent accessible alternatives see examples in the training and reference materials. Also see Section: 19.0 Alternate Accessible Versions.

Guidelines:

Access VT: Make content and functionality accessible 14.2
WCAG 6.2, 11.4
Section 508 k

Go to Table of Contents

Section: 15. Downloadable Documents

15.1 - Provide accessible versions of downloadable documents whenever possible.

What:

Downloadable documents are often provided in formats such as Adobe Acrobat PDF, Microsoft Word, or Rich-Text-Format (RTF), as well as HTML and plain text. Some documents must be viewed in their own applications or require a web browser plug-in, and or may not be formatted for accessibility.

Why:

The applications required to open downloadable documents may not be available and/or some content may not be accessible to users with disabilities.

How:

For each page that contains a downloadable document, provide a link to the viewer or browser plug-in needed to view the document. The content of any downloadable document should be accessible. Accessibility would at a minimum require that the document be formatted to ensure proper reading order and text descriptions added for images, charts, graphs, or other non-text content. In addition, links to a HTML or "Printer Friendly" version of the document be provided for files that are not HTML or text .

Guidelines:

Access VT: Downloadable Documents 15.1


15.2 - If a downloadable document cannot be provided in an accessible electronic format, provide information on how to request an alternative format.

What:

In some cases, downloadable documents cannot be provided in an accessible electronic format.

Why:

Users with documented disabilities and certain disability accommodations may request equivalent access to documents that are not in an accessible electronic or alternative format on university websites.

How:

Provide information on the website regarding whom to contact, such as the Webmaster, to obtain documents in alternative formats, for example: captioning for a live video or audio presentation; Braille, large-print, etc. for printed materials listed on a website; or audio formats (MP3, cassette, etc.) for persons with a documented print disability and an accommodation to use audio formats. Alternative formats must be made available in a timely manner.

Guidelines:

Access VT: Downloadable Documents 15.2

Go to Table of Contents

Section: 16. Window Control

16.1 - Notify users of actions that will open a new window.

What:

It is possible to cause hypertext links to open pages in a new browser window, or to automatically open additional windows when a page loads or unloads.

Why:

It may not always be obvious to users, especially those with limited vision, blindness, or cognitive disabilities, when a new window has opened. It can be confusing when features such as the browser's "back" button no longer work as expected.

How:

Avoid automatically opening new windows. Clearly identify any links that will open new windows by providing an indication in the link text or title attributes.

Guidelines:

Access VT: Window Control 16.1
WCAG 10.1


16.2 - Do not automatically refresh the current page.

What:

It is possible to cause web pages to automatically re-load their content on a certain interval. For example, a page containing news headlines might refresh every few minutes to present the most current items. Also see (8.2 - Avoid uncontrolled animation and/or loop elements).

Why:

When a page automatically refreshes, it can cause a screen reader to re-start reading from the beginning of the page.

How:

Do not use HTTP-EQUIV="refresh". If necessary, provide a link or control to allow the user to refresh a page at his or her discretion.

Guidelines:

Access VT: Window Control 16.2
WCAG 7.4


16.3 - Notify users of time limits and provide a means to extend time if needed.

What:

Some web pages, frequently those that require a user to log in with an ID and password, "reset" themselves after a certain period of inactivity. Typically, any form entries that have been partially completed are erased and the user must start over.

Why:

Users with visual, physical, or cognitive disabilities may require more time than average to read and interact with a web page.

How:

Provide a clear explanation of any time limits and offer the user a way to extend or remove the limits when necessary and permissible. Avoid using time limits unnecessarily.

Guidelines:

Access VT: Window control 16.3
WCAG 7.5
Section 508 p

Go to Table of Contents

Section: 17. Page Layout

17.1 - When using tables for layout, make sure that reading order is logical.

What:

Layout tables are HTML tables used to format a web page in multiple columns and sections (as opposed to tables that actually present data.) "Reading order" refers to the order in which a screen reader would read through the table. For example, the reading order for a simple table might be (1) row 1, cell 1, (2) row 1, cell 2, (3) row 2, cell 1, and (4) row 2, cell 2.

Why:

Screen reading programs read through tables in the order in which cells are defined in the table code, which can be very different from the order that someone reading visually would follow. It is essential that the reading order match the logical flow of the document so that a screen reader user’s experience would match that of a visual reader’s experience.

How:

Check the reading order by following the order in which the table cells appear in the code. It may be possible to combine cells and/or nest tables to achieve an appropriate reading order.

Guidelines:

Access VT: Page Layout 17.1
WCAG 5.3


17.2 - When using style sheets for layout, make sure that reading order is logical when style sheets are not supported.

What:

The positioning features of Cascading Style Sheets (CSS) can be used to position elements visually almost anywhere on a web page.

Why:

As with layout tables, screen readers read through the elements on a web page in the order in which they appear in the page code, regardless of how they are positioned using style sheets. It is essential that the reading order match the logical flow of the document so that a screen reader user would hear the document in the same order that a visual reader would read it.

How:

Check the reading order by following the order in which elements appear in the page code. Reading order can usually be adjusted by rearranging the order in which elements are defined in the code.

Guidelines:

Access VT: Page Layout 17.2
WCAG 6.1
Section 508 d


17.3 - Minimize the need for horizontal scrolling.

What:

If a web page is wider than the window or screen in which it is viewed, most browsers will display a horizontal scroll bar and require the user to manually scroll to see the entire page.

Why:

When a screen magnifier enlarges a web page, it also reduces the field of view so that the user must pan (scroll) to see the entire page. When the web page being viewed also requires horizontal scrolling, the combination can be awkward or unusable. Keyboard users may also find repetitive scrolling fatiguing and inefficient.

How:

Design pages so that they can resize to fit the width of the user's browser. Use relative widths on tables and frames used for layout and make sure that horizontally adjacent images are less than a total of 600 pixels wide. If scrolling cannot be avoided, place the least important content in the rightmost part of the page.

Guidelines:

Access VT: Page Layout 17.3
WCAG 3.4


17.4 - Utilize page dimensions that are safe for graphics and printing.

What:

If a web page includes graphics and content wider than the page on which it is to be printed, a browser will either scale the page content to fit the selected paper width or it will cut content off at the right margin.

Why:

Although a browser may have an option for wide pages to be scaled to fit a selected print size, excessive scaling can create graphics and content that are illegible or unreadable when printed. Should a scaling option be unavailable or turned off, the printing of wide pages will generally result in graphics or content being cut off at the right margin.

How:

Proper utilization of CSS can help avoid illegible or unreadable documents when printed. If using CSS is not possible, design a web page that has relative sizes (percentages) for the width of the content. Otherwise, create web pages with dimensions that are safe for graphics and printing.

Guidelines:

Access VT: Page Layout 17.4

Go to Table of Contents

Section: 18. Page Content

18.1 - Use the clearest and simplest language appropriate for a page’s subject matter.

What:

"Clearest and simplest language" refers to the words and grammar used in the content of a web page. It is a subjective goal that depends on the subject matter and intended audience of each web page.

Why:

Clear and simple language is easier for all readers, and especially those with cognitive or learning disabilities. Simple language also helps individuals whose primary language is American Sign Language, which differs significantly from written English.

How:

Be concise and avoid jargon. Have someone else proofread your text. Do user testing with people from your intended audience when possible.

Guidelines:

Access VT: Page Content 18.1
WCAG 14.1

Go to Table of Contents

Section: 19. - Alternate Accessible Versions

19.1 - Use alternate accessible versions only as a last resort.

What:

Separate accessible or "text-only" versions are often offered instead of providing a single accessible site.

Why:

Manually developing and maintaining a separate "text-only" version of an entire site is tremendously demanding of time and resources. In practice, alternate accessible "text-only" versions are rarely kept up-to-date or complete. Given advances in accessibility techniques and assistive technologies, "text-only" sites are simply not necessary in most cases

How:

Follow Virginia Tech web accessibility standards to develop a single site that is universally accessible and efficient to maintain.

Guidelines:

Access VT: Alternate Accessible Versions 19.1
WCAG 11.4
Section 508 k

Go to Table of Contents

Section: 20. Contact Information

20.1 - Provide contact information.

What:

A contact entity to report accessibility issues, such as a Webmaster, should be identified for all websites.

Why:

Individuals with disabilities may need to report accessibility issues or request information from a website in an alternate accessible format.

How:

List contact information on the home page or a separate contact page. Inquiries about accessibility, especially requests for materials in alternate format, need to be handled in a timely manner by the Webmaster or contact person.

Guidelines:

Access VT: Contact Information 20.1

Go to Table of Contents

Section: 21. Test for Accessibility

21.1 - Test for Accessibility

What:

Involve users and automated evaluation methods when testing a website for accessibility and usability.

Why:

Testing determines whether accessibility and usability goals for a website have actually been accomplished.

How:

Use automated accessibility verification and repair tools supported by the university to identify accessibility and usability problems or to identify content or functionality needing user testing. Then have people knowledgeable of disability issues and/or accessibility standards conduct a website review starting with automated test results. User testing should include evaluating the use of university supported web browsers, assistive technologies, and reviewing the website content for completeness, clarity of language, and ease of navigation.

Guidelines:

Access VT: Testing 21.1

Go to Table of Contents

Copyrights and Permissions: Web Content Accessibility Guidelines (WCAG) 1.0 of the Web Access Initiative (WAI) are a product of the World Wide Web Consortium (W3C) Copyright © 1994-2003. Portions of guidelines reproduced with additional permissions from the Commonwealth of Virginia, the State of Illinois, and the State of Maine with W3C Copyright © reserved.

Quick Reference

Go to Default Version

Virginia Tech
Web Accessibility
Standards and
Guidelines

Version 2007-001

Reference Section:

  1. Coding
  2. Text
  3. Colors
  4. Images
  5. Image Maps
  6. Audio
  7. Multimedia
  8. Animation
  9. Links
  10. Forms
  11. Data Tables
  12. Frames
  13. Scripts
  14. Applets and
    Plug-Ins
  15. Downloadable
    Documents
  16. Window Control
  17. Page Layout
  18. Page Content
  19. Alternate Access-
    ible Versions
  20. Contact Information
  21. Accessibility Testing

Contact Information

Request for Comments
Send an e-mail to assist@vt.edu