Logo: Accessibility Learning PathA certification for this topic is available in the Accessibility Learning Path. The self-paced Canvas course includes detailed how-to instructions and self-check exercises.

Page Content

Synopsis of Testing Protocol

This protocol will help you address major accessibility errors for a given Web page.

  1. Use the triage method to determine high priority pages for large websites.
  2. Use automated testing tools like WAVE toolbar and others testing tools to run checks on Web pages to find key content and template errors.
  3. Ensure that all videos are captioned and audio described as needed and that audio-only files are transcribed.
  4. If you use style sheets, then disable stylesheets to ensure content is in a usable order with style sheets turned off. This is the order that will be presented to screen readers or to a low vision user using an alternate high-contrast stylesheet.
  5. Attempt to operate your website with just the keyboard (but not in a screenreader). This test shows how well a mobility impaired user can access your system.
  6. Use a color contrast checker to ensure there is adequate contrast between the background and foreground text for WCAG AA compliance.
  7. View your website with a grayscale filter or color deficient vision simulator or to ensure that content is not dependent on color.
  8. Make sure that all content is available in a screen reader. This is especially important for pages containing dynamic elements, Flash, Javascript elements or other content not easily tested in a reporting tool. See Screen Reader Testing
  9. View your content in different monitor sizes and at extreme levels of zooming. Content should not overlap at extreme zoom used by low vision users.

Streamline the Protocol

Triage Your Pages

Accessibility Site Triage is a process developed by the TLT Web Accessibility Team to quickly bring a website to an acceptable, if not perfect, level of compliance with current standards (WCAG 2.0 comformance level AA).

In addition to service sites, triage can be applied to a list of courses (i.e. accessify large enrollement courses first) or a suite of online services maintained by one unit.

Streamlining Tests

Although the protocol above involves multiple tests, not every test needs to be done on every page. For example, a check for video captions is only needed for a page with videos. This is especially true of pages using a common CSS file and common CMS template.

See the table below for recommended guidelines on how to apply tests.

Test Which Pages
WAVE or Automated Scan Pages or Site
Screen Reader
  1. Home page and sample content page,
  2. Pages with slideshow, dropdown menu, interactive media or unusual plugins
  3. Web application pages
Captions/Transcription Pages with video or audio
Disable Stylesheet
  1. Home page
  2. Sample content page
  3. Unique page layout
Keyboard
  1. Home page
  2. Sample content page
  3. Page with Flash object, slideshow, dropdown menu or unusual plugins
  4. Web application pages
Contrast, Color
  1. Home page
  2. Sample content page
  3. Page with unique color scheme

Accessibility Reports

A variety of organizations and companies have developed tools to "scan" Web
pages and see if they are accessible or not. Although these tools can catch some errors like missing ALT
or TH tags, they cannot catch all errors. You must still use the manual checks above to determine that all accessibility requirements have been met.

Common Reporting Tools

Some common reports include:

  • FAE/AInspector – Accounts available to all Penn State staff.
  • WebAIM Wave Toolbar – This presents the visual structure of a page with a series of icons. Icons colored red or yellow are indications of problem areas.

Lists of Manual Checks

For errors that cannot be caught automatically, a list of manual checks, is generated. Therefore a completly compliant site could still generate a list of items to check depending on the reporting tool – this is perfectly normal.

Limits of Accessibility Reports

Below are some advantages and limits of accessibility reporting tools.
(Chart based on content from the University Libraries)

HTML Element Reports CAN Reports CANNOT
Images Check for Missing ALT tags Verify that ALT tags are accurate
Headings Determine if headings are properly nested and possibly detect large text NOT formatted as a heading Always check if text formatted as a heading IS a heading.
Color Suggest manual color check Simulate color blindnesss modes
Data Tables Identify most missing TH tags Check that tables are coherent when read left-to-right, top-to bottom
Flash Objects Suggest manual check Determine accessibility of Flash forms or interactive modules
Style Sheets Suggest manual check without CSS sheets Check stylesheets for accessibility
Links Identify large blocks of links Identify links which are vaguely worded or too close together
Forms Identify missing LEGEND, LABEL and ID tags Fix them for you automatically or ensure that they are accurate
Javascript Suggest manual NOSCRIPT check Automatically insert a NOSCRIPT alternative
HTML Code Validation Do nothing HTML and XHTML validation is completely different tool or report

Screen Reader Testing

Screen reader tests are particularly valuable for elements which cannot be checked in any other reporting tool. These include Flash objects, interactive elements and unique plugins and documents.
NOTE: It is also recommended to use screen readers on static sites to learn how they operate for users.

Multiple screen readers can also be tested to verify the behavior of new applications or unusual HTML (and HTML 5) tags or new CSS styles in each screen readers. Common screen reader tools include

Blind vs. Non-Blind Testers

Although it is ideal to have blind users test new sites and services to ensure that the interface is usable, a sighted user can also provide valuable testing data because they can see what is on the screen and listen to the screen reader at the same time.

Sighted users can spot items which are on the screen but NOT read by a screen reader.

Disable Stylesheets

Tools to disable stylesheets are available in the WebAIM Wave Toolbar among other plugins.

Disabling stylesheets on a website can show the likely reading order of elements in a screen reader. Once stylesheets are disabled, items which have been placed by absolute positioning or floats will move to their actual location in the code.

This test not only shows the order on a screen reader but shows what may appear if a low vision user chooses to override the CSS with a custom stylesheet.

Keyboard Testing

Keyboard testing refers to the process of using a series of keystrokes to navigate a Web site. Keyboard navigation is critical for somone who cannot use the mouse – either because of issues manipulating a hand or lack of vision.

The following keyboard commands are common for web pages.

Note: This is separate from a screen reader test because screen readers include additional keyboard commands not available in a visual browser.

Contrast and Color Testing

These tests determine how legible a color scheme is to low vision and color deficient users. Learn more about these tests on the Contrast page and Color issues page.

Top of Page

Last Update: September 21, 2023