Guidelines

Web Content Accessibility Guidelines 2.0

Provide text alternatives for non-text content (e.g. images)
WCAG 2.0 level A (minimal conformance)

Equivalent to 1a (Section 508)

All images and other non-textual items should have a text alternative that describes what it is, so that blind users are able to understand these items.

  • Provide all images with a descriptive ALT attribute, or an empty string (alt="") if it is a purely decorative image.
  • Provide a descriptive TITLE attribute for all embedded audio/video, non-image charts, Flash, form elements and other items that require textual explanation in order to be understood.
  • Do not use CAPTCHA that relies on visual identification
  • Decorative images such as icons should preferably be displayed using CSS rather than directly in HTML

How to test: Use AChecker and look for images with missing ALT attributes. Manually check that the text descriptions provided by ALT and TITLE attributes are clear and descriptive

External links: W3C
Provide alternatives for time-based media (audio and video)
WCAG 2.0 level A (minimal conformance)

Audio and video should be provided with a text-based transcript so that the content is accessible to blind or deaf users.

  • Prerecorded video without an audio track should have a textual transcript describing what it shown in the video.
  • Prerecorded audio should have a textual transcript describing what is said or played in the audio

How to test: Check if audio or video is present. If so, check that a transcript is available.

External links: W3C
WCAG 2.0 level A (minimal conformance)

Pre-recorded audio should be captioned with text describing what is said and what happens, so that the audio is accessible to deaf users.

How to test: Check if audio is present. If so, check that captions are available.

External links: W3C
WCAG 2.0 level A (minimal conformance)

All video with an audio track should be made accessible to blind users, by providing descriptions of everything that happens.

Descriptions can be provided either textually or as part of the audio track.

How to test: Check if video is present. If so, check that textual or audio descriptions are available.

External links: W3C
Content can be presented in different ways (e.g. through a screen reader) without losing info or structure
WCAG 2.0 level A (minimal conformance)

This is to ensure that being able to see the page, including its visual layout and color use, is not required in order to be able to understand the information presented.

  • The structure and meaning of the page can still be understood when all CSS styling is removed.
  • HTML elements should be used to define the structure and meaning of the elements on the page, including headings, lists, paragraphs, and table elements (including row and column headers).
  • Color is not used as the only means to convey meaning. For example, required fields in a form can also be indicated using text labels ("Required") or asterisks (provided an explanation is given of these asterisks)

How to test:

  • Use the Web developer toolbar to remove all CSS styling.
  • Use a tool like WAVE > Outline to check the headings.
  • Check manually that the correct HTML markup is used for elements such as tables, headings and lists, and that color is not used as the only means of providing information.
External links: W3C
WCAG 2.0 level A (minimal conformance)

Equivalent to 1d (Section 508)

This is to ensure users do not need to be able to see the visual layout of the page in order to understand the correct order of the information presented.

  • When all CSS styling of the page is removed, the elements on the page are still in a logical reading order in the HTML code.
  • Make sure the tabbing order of the page elements is logical. If necessary, use the tabIndex property to enforce the correct tabbing order.

How to test:

  • Use the Web developer toolbar to remove all CSS styling.
  • Check manually that the elements on the page are in a logical reading order and that the tabbing order is logical.
External links: W3C
WCAG 2.0 level A (minimal conformance)

Users should not be required to identify elements solely by their shape or their position on the page.

  • Some examples of what NOT to say: "the button on the right", "the left-hand sidebar", "the round button", "the sounds that chimes".
  • In on-screen help texts and instructions, identify elements by multiple characteristics, such as the label, color and position, e.g. "the green button 'Next' on the right"
  • When using beeps or other sound cues to inform the user of an event, display a textual message as well.

How to test: Check manually.

External links: W3C
Make sure content is readable and the foreground contrasts sufficiently with the background
WCAG 2.0 level A (minimal conformance)

Equivalent to 1c (Section 508)

Color should not be used as the only means of conveying information, because blind users are not able to see colors, and colorblind or older users may not see colors correctly.

  • When using color to convey information, use another means (like text) to convey the same information in another way
  • Do not rely solely on color to identify links. Distinguish links from regular text by underlining them, bolding them, showing an icon next to each link, or some other means other than color.
  • In forms, use not just color but also text labels to identify required fields or fields with errors

How to test: Check manually.

External links: W3C
WCAG 2.0 level A (minimal conformance)

For audio that plays longer than 3 seconds, users should be able to pause or stop the audio, or change the volume of the audio.

This is to ensure that blind users can hear their screen reader software speak aloud the page. The spoken text is not interrupted by an audio clip.

  • Offer audio controls for all audio clips

How to test: Check if audio is present. If so, check that controls are present.

External links: W3C
Make all functionality available from a keyboard
WCAG 2.0 level A (minimal conformance)

This ensures that the site can be accessed using a keyboard only.

Blind users cannot use a mouse; they must use the keyboard to navigate Web pages. Users with hand tremors and other motor skills also have trouble using a mouse.

  • All clickable items should also be selectable using the keyboard
  • Where "drag and drop" functionality is used, a keyboard-based "cut and paste" alternative should be offered
  • Do not use non-standard interface elements that are not keyboard-accessible but can be controlled with a mouse only

How to test: Check manually by tabbing through the page and checking all interactive elements for keyboard accessibility.

External links: W3C
WCAG 2.0 level A (minimal conformance)

Users navigating a Web page using the keyboard should not become trapped on a particular element or section of the page.

This is a particular issue for Java applets, Flash files and other plugins. Once the user has entered one of these, they must be able to leave them again using the keyboard only.

How to test: Check manually by tabbing through the page and checking for keyboard traps.

External links: W3C
Give users enough time to read and use content
WCAG 2.0 level A (minimal conformance)

This allows users to extend or turn off time limits. For each time limit one of the following should be true:

  • The time limit can be turned off beforehand
  • The time limit can be extended beforehand
  • The user is warned before a time limit expires and given at least 20 seconds to extend the time limit

Exceptions can be made where the time limits are essential or longer than 20 hours.

How to test: Check manually if time limits are present. If so, check that they are compliant.

External links: W3C
WCAG 2.0 level A (minimal conformance)

Users should be able to pause, stop or hide any moving, blinking or automatically updating content on the page.

Content that is constantly changing can be problematic for users who have trouble reading text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen reader software.

  • This pertains to content that starts automatically and lasts more than five seconds
  • This can be onscreen text as well as video, audio or animation

How to test: Check manually if moving, blinking or automatically updating content is present. If so, check that it is compliant.

External links: W3C
Do not use content that can cause seizures
WCAG 2.0 level A (minimal conformance)

This ensures that users with epilepsy and other who have photosensitive seizure disorders do not get seizures from content that flashes onscreen.

How to test: Check manually if flashing occurs. If so, check that it is compliant.

External links: W3C
Help users to navigate, find content, and determine where they are
WCAG 2.0 level A (minimal conformance)

Equivalent to 1o (Section 508)

This allows blind users, who use screen reader software, to skip the page header, navigation menus and other content that is repeated on every page, and go straight to the main content on the page.

How to test:

  • Use the Web developer toolbar to remove all CSS styling
  • Check for the presence of "skip" links
External links: W3C
WCAG 2.0 level A (minimal conformance)

Each page should have a title clearly describing the topic or purpose of that page.

This helps users orient themselves within the site and understand the purpose of the current page.

  • Use the <title> tag in the HTML page header

How to test: check what is shown on the browser tab, or bookmark the current page.

External links: W3C
WCAG 2.0 level A (minimal conformance)

This allows blind users and others accessing the site through a keyboard to move through the page elements in a logical reading order

  • The tabIndex property can be used to enforce a certain tabbing order
  • When the user leaves a modal dialog box on the page, they should not lose their focus on the page and have to start from the top of the page again. Instead, the element that had the focus when the modal dialog opened should get the focus again

How to test:

  • Tab through the interactive elements on the page
  • Open and close modal windows using the keyboard only
External links: W3C
WCAG 2.0 level A (minimal conformance)
Tags: links

The purpose or target of each link should be clear from the text (label) of that link, or from the sentence in which the link appears

  • Make sure each link is clearly labeled
  • When the link text or context is not clear enough, give the link a title property with a clear description of the link purpose or target, e.g. <a href="page.html" title="View more details about this person">John Smith</a>

How to test: Manually check each link on the page to verify that it is clearly labeled.

External links: W3C
Text should be readable and understandable
WCAG 2.0 level A (minimal conformance)

This allows screen reader software (used by blind users) to use the correct pronounciation when speaking the text on the page aloud.

  • Identify the primary language of a Web page in the HTML page header, e.g. <html lang="en"> for English in HTML5.

How to test: Use a tool like AChecker or WAVE, or inspect the HTML code.

External links: W3C
Make Web pages appear and operate in predictable ways
WCAG 2.0 level A (minimal conformance)

No unexpected actions should occur when a particular UI element receives keyboard focus. This can be very confusing to blind users and other keyboard-only users.

Some examples of what should NOT happen at the moment a component receives the focus:

  • a form is submitted automatically
  • a new window is openened
  • the focus is changed to another component

How to test: Go through the form elements on the page and check for unexpected actions.

External links: W3C
WCAG 2.0 level A (minimal conformance)

No unexpected actions should occur when the user makes changes to a particular UI element. This can be very confusing to blind users and other keyboard-only users. Some examples of changes to a UI element are:

  • turning a checkbox or radio button on or off
  • selecting a different item from a dropdown menu
  • entering text into a text field

Some examples of what should NOT happen:

  • a new window is openened
  • the content on the page changes

How to avoid unexpected actions:

  • Provide a submit button. Do not perform any actions until this button is clicked by the user

How to test: Go through the form elements on the page and check for unexpected actions.

External links: W3C
WCAG 2.0 level AA

This ensures that blind users can find navigation menus in the same place on the page every time.

This also applies to other items repeated on every page, such as:

  • a search box
  • login/registration and links to edit your user account or preferences
  • a "Skip to content" link

How to test: Go through the site and check that the main navigation menus look and work the same on every page.

External links: W3C
Help users to avoid and correct mistakes
WCAG 2.0 level A (minimal conformance)

This ensures that users are clearly informed of input errors in forms.

  • Display an error message with text alerting the user to the specific fields (or other form elements) containing errors and describing the specific errors in the input
  • Color or images can be used in addition to the text to mark the form elements containing errors

How to test:Submit each form on the page with errors and inspect the resulting messages and other feedback given.

External links: W3C
WCAG 2.0 level A (minimal conformance)

All fields and other form elements ar clearly labeled, or instructions for correct entry are provided

  • Use the <label for="[element ID]"> HTML tag to associate a form element with its label
  • Label all form elements. Use clear, unambiguous labels
  • Identify required (mandatory) fields with a text label. Do not use color or images only to identify required fields.
  • Display the label for an element in close proximity to that element
  • Provide examples of correct input, such as the correct date format

How to test:

  • Use AChecker to check for form elements that are not (properly) labeled.
  • Go through the forms on the page and check that each form element is clearly labeled.
External links: W3C
Maximize compatibility with assistive technologies (such as screen readers) and future browsers
WCAG 2.0 level A (minimal conformance)

Valid HTML ensures that both screen reader software and browser can accurately render the content

  • HTML code should pass W3C's HTML validation tool
  • Use unique IDs - no two elements on the same page should have the same ID
  • Browser add-ons like Firebug can be used for quick HTML validation during development
  • HTML5 is recommended because it is a lot more forgiving than previous versions of HTML

How to test:

  • Use W3C's HTML validation service to validate the HTML code.
  • Use a tool like AChecker and WAVE to check for duplicate IDs
External links: W3C
WCAG 2.0 level A (minimal conformance)

The name and state of all form elements, links and other UI components can be determined and the state can be changed. This ensures compatibility with assistive technology such as screen readers, screen magnifiers, and speech recognition software

  • Avoid using non-standard controls such as those created by Flash, Java or other plugins, components that are created using scripting, or clickable <div>s and <span>s
  • When using non-standard controls, make sure that it is keyboard accessible - it can receive focus and its state can be changed using the keyboard

How to test:

  • Use AChecker to check for clickable <div>s and <span>s
  • Go through the (non-standard) form elements on the page and check for unexpected actions
External links: W3C

Section 508 Amendment to the U.S. Rehabilitation Act

Standards for Web-based content (§1194.22)

Equivalent to 1.1.1 (WCAG 2.0)

All images, audio/video, embedded plug-ins (such as Flash and Java) and other non-textual items should have a text alternative that describes what it is, so that blind users are able to understand these items.

  • Provide all images with a descriptive ALT property, or an empty string (alt="") if it is a purely decorative image.
  • Decorative images such as icons should preferably be displayed using CSS rather than directly in HTML
  • Provide a descriptive TITLE property for all embedded audio/video, non-image charts, and plug-in content such as Flash.
  • Instead of ALT or TITLE properties, you can also provide an onscreen text description of elements
  • Provide text transcripts for audio content
  • Preferably, display decorative images such as icons using CSS rather than directly in HTML

How to test: Use AChecker and look for images with missing ALT attributes. Manually check that the text descriptions provided by ALT and TITLE attributes are clear and descriptive

This ensures that all audiovisual content is accessible to blind and deaf users.

  • Provide text captions for video and live audio broadcasts
  • Provide video without an audio track with an audio description of the video

How to test: Check if audio or video is present. If so, check that captions and audio descriptions for video.

Equivalent to 1.4.1 (WCAG 2.0)

Color should not be used as the only means of conveying information, because blind users are not able to see colors, and colorblind or older users may not see colors correctly.

  • When using color to convey information, use another means (like text) to convey the same information in another way
  • Do not rely solely on color to identify links. Underline links when hovering over them
  • In forms, use not just color but also text labels to identify required fields or fields with errors

How to test: Check manually.

Equivalent to 1.3.2 (WCAG 2.0)

This is to ensure users do not need to be able to see the visual layout of the page in order to understand the correct order of the information presented.

  • When all CSS styling of the page is removed, the elements on the page should still be in a logical reading order in the HTML code

How to test:

  • Use the Web developer toolbar to remove all CSS styling.
  • Check manually that the elements on the page are in a logical reading order.

Server-side image maps are not accessible to blind users and require a text alternative.

  • Provide text links as an accessible alternative for each clickable region of the image map
  • The use of image maps is outdated and best avoided altogether

How to test: Check if server-side image maps are used by inspecting the HTML code (look for <img> tags with an ismap attribute). If so, check that they are compliant.

Tags: images

Server-side image maps are not accessible to blind users.

  • Use client-side image maps instead of server-side image maps
  • The use of image maps is outdated and best avoided altogether

How to test: Check if client-side image maps are used by inspecting the HTML code (look for <map> tags). If so, check that they are compliant.

When tables have a header row and/or column, the header should be identied using HTML

  • Use <th scope="col"> for cells in a header row along the top of the table
  • Use <th scope="row"> for cells in a header column along the left-hand side of the table

How to test: Check if tables maps are used by inspecting the HTML code (look for <table> tags). If so, check that header rows and columns are correctly marked up.

When tables have a header row and/or column, use the scope attribute to mark header cells as the header of that row or the header of that column

  • Use <th scope="col"> for cells in a header row along the top of the table
  • Use <th scope="row"> for cells in a header column along the left-hand side of the table

How to test: Check if tables are used by inspecting the HTML code (look for <table> tags). If so, check that header rows and columns are correctly marked up.

HTML frames can cause problems for screen reader software.

  • When frames are used, each <frame> tag should have a title attribute with a description of the purpose of content of that frame
  • The use of frames is outdated and best avoided altogether

How to test: Check if frame by inspecting the HTML code (look for <frameset> and <frame> tags). If so, check that each <frame> tag has a descriptive title attribute.

This ensures that users with epilepsy and other who have photosensitive seizure disorders do not get seizures from content that flashes onscreen.

  • No element on the page should flash at a rate of 2 to 55 cycles per second

How to test: Check manually if flashing occurs. If so, check that it is compliant.

When a page cannot be made fully accessible, a text-only version of that page should be offered as an accessible alternative

  • Only specific pages that are not fully accessible need a text-only alternative, not the entire site
  • Make sure the text-only version of the page offers the same information as the full version

How to test:

  • Determine whether the page contains any elements that are not fully accessible.
  • If so, check whether there is a link on the page to a text-only version.
  • Check also that the text-only version is identical in content and functionality to the standard version.

Page content added or changed using JavaScript (e.g. navigation menus or content added using AJAX) can be inaccessible to screen reader software or keyboard-only users.

  • When using JavaScript to create UI elements, make sure the content is accessible using a keyboard only or using a screen reader.
  • When using JavaScript to open a pop-up window, make sure the pop-up is semantically related to the link (using ARIA) and set the keyboard focus inside the pop-up.
  • Avoid ondblclick, onmousedown and onmouseup event handlers as these are inaccessible to keyboard-only users
  • Avoid onfocus and onblur event handlers as these can cause unexpected behavior for users of screen reader software

How to test:

  • Check if JavaScript links are present on the page
  • If so, make sure the content added or changed by these links is keyboard accessible and can be read by screen readers.

Content provided by Java applets and plugins such as Flash and Silverlight is often inaccessible to screen reader users.

When a Web page requires an applet, plug-in or other application to interpret page content, the page must provide a link to download the plugin or applet.

  • Any plug-in used should meet the accessibility requirements as set out in §1194.21 (2a through 2l in the Section 508 guidelines)
  • When a plug-in is used that is not fully accessible, provide an accessible alternative
  • When a plug-in is used, provide a link to download that plug-in
  • The use of plug-ins is outdated and best avoided altogether

How to test:

  • Check if third-party software (plug-in, add-on) is used on the page, such as Java, Flash, Silverlight, QuickTime, Shockwave, RealAudio or a third-party PDF viewer.
  • If so, check if there is a link on the page to download and install the plug-in.

This is to ensure that forms are fully accessible to users of screen reader software

  • All form elements should be keyboard accessible
  • Label all form elements. Use clear, unambiguous labels
  • Use the <label for="[element ID]"> HTML tag to associate a form element with its label
  • Identify required (mandatory) fields with a text label. Do not use color or images only to identify required fields.
  • Warn about errors in input with a text message. Identify the specific form elements with errors and describe the specific errors. Do not use color or images only to identify errors.
  • Provide examples of correct input, such as the correct date format

How to test:

  • Check if there are forms or form elements on the page.
  • If so, check that all form elements are clearly labeled and fully keyboard accessible.
  • Submit each form with errors and check that errors are clearly identified and described to the user.

Equivalent to 2.4.1 (WCAG 2.0)

This allows blind users, who use screen reader software, to skip the navigation menus and other content that is repeated on every page, and go straight to the main content on the page.

How to test:

  • Use the Web developer toolbar to remove all CSS styling
  • Check for the presence of "skip" links

Equivalent to 2.2.1 (WCAG 2.0)

This allows users to be aware of time limits and and extend them before the page times out.

  • Warn users of time limits
  • Give users the option to extend a time limit within a reasonable amount of time

How to test: Check manually if time limits are present. If so, check that they are compliant.

Standards for software applications (§1194.21)
These standards also apply to software applications that are embedded in or deployed on Web sites, such as Flash, QuickTime and Java applets

This ensures that the application can be accessed using a keyboard only.

Blind users cannot use a mouse; they must use the keyboard to navigate. Users with hand tremors and other motor skills also have trouble using a mouse.

  • All actions that are labeled with text should be executable from a keyboard.

This ensures that documented accessibility features are always available to users.

  • A software application or API may not disrupt or disable the accessibility features of an application or the operating system.
  • A few examples of accessibility features are:
    • changing the color scheme
    • enlarging a part of the screen
    • providing "sticky keys" that allow a user to press key combinations (such as control-C) sequentially rather than simultaneously.

This ensures that users who are unable to use a mouse can access the site using a keyboard. It also enables people to use assistive technology like screen enlargement, screen reader or Braille reader software.

  • The element with the current keyboard focus should be visibly marked onscreen. This allows users to see where the focus is and track it as it moves across the page.
  • The element with the current keyboard focus can be programmatically determined. This allows assistive technology software to function properly.

This ensures that all user interface elements are understandable and accessible to users of screen reader software.

  • When using images for a user interface element to indicate its identify, operation or (where relevant) its current state, offer a text alternative
  • This pertains to any other feature that allows the user to perform some action, such as buttons, checkboxes, radio buttons, menus, toolbars, and scrollbars.
  • You can provide a text alternative by providing the UI element with a TITLE property. This is preferable to giving the description in the ALT property of the image.

This ensures consistency in how images are used for user interface elements. It is particularly important to users of screen reader software, which provides the ability to assign text names to images. If the meaning of an image is not always the same, the assigned text name will not always be valid.

  • Always use the same image for the same user interface element, throughout the application
  • UI consistency benefits all users, not just those who use assistive technology

This ensures that all text elements can be read and accessed by users of screen reader software, including text fields in forms

  • The use of images for text is outdated and best avoided altogether.
  • Blind and colorblind users and users with low vision often change the operating system settings, for instance increasing the zoom or setting a high-contrast color scheme. The application should respect and not override these personal settings.

    Animations can present problems to users of screen reader software and other assistive technology, particularly those with visual and learning disabilities

    • When animations are used, provide a non-animated alternative such as text or non-animated images.
    • Give users the option to start, pause or stop, and step through animated content.
    • When using an animated carousel, make sure the user can freeze the animation

    Color should not be used as the only means of conveying information, because blind users are not able to see colors, and colorblind or older users may not see colors correctly.

    • When using color to convey information, use another means (like text) to convey the same information in another way
    • Do not rely solely on color to identify links. Underline links when hovering over them
    • In forms, use not just color but also text labels to identify required fields or fields with errors

    Blind and colorblind users and users with low vision often change the color and contrast settings, for instance setting a high-contrast color scheme. The application should provide a variety of color and contrast settings for various types of users.

    This ensures that users with epilepsy and other who have photosensitive seizure disorders do not get seizures from content that flashes onscreen.

    • No element on the page should flash at a rate of 2 to 55 cycles per second

    This is to ensure that forms are fully accessible to users of screen reader software

    • All form elements should be keyboard accessible
    • Label all form elements. Use clear, unambiguous labels
    • Identify required (mandatory) fields with a text label. Do not use color or images only to identify required fields.
    • Warn about errors in input with a text message. Identify the specific form elements with errors and describe the specific errors. Do not use color or images only to identify errors.
    • Provide examples of correct input, such as the correct date format