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 testing tools like FAE/AInspector 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 is 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 color deficient vision simulator or grayscale 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
FAE Scan 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
  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

Disabling stylesheets on 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.

Tools to disable stylesheets are available in these Firefox plugins among others.

Keyboard Testing

Keyboard testing refers to the process of using a series of keystrokes (usually the Tab key to move forward, Shift+Tab to move backwards and Enter to click a button) to navigate a page and determine if links can be accessed and forms completed without using the mouse. This tests the accessibility of a Web site to a motion impaired user unable to use a mouse.

Other applications (e.g. Microsoft Office or a Flash application), should include keyboard equivalents (e.g. CONTROL+P for print) for all functions.

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

The following sites include information on keyboard shortcuts for specific browsers and system setup.

Note: Many keyboard shortcuts have been standardized across the browsers

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