This Page
Synopsis of Testing Protocol
This protocol will help you address major accessibility errors for a given Web page.
- Use the triage method to determine high priority pages for large websites.
- Use testing tools like FAE/AInspector and others testing tools to run checks on Web pages to find key content and template errors.
- Ensure that all videos are captioned and audio is transcribed.
- 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.
- 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.
- Use a color contrast checker to ensure there is adequate contrast between the background and foreground text for WCAG AA compliance.
- View your website with a color deficient vision simulator or grayscale to ensure that content is not dependent on color.
- 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
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 |
|
| Captions/Transcription | Pages with video or audio |
| Disable Stylesheet |
|
| Keyboard |
|
| Contrast, Color |
|
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
- JAWS – used by approximately 65% of blind users
Note: JAWS is available in - Voiceover – free on a Mac or iPhone/iPad
- NVDA – free for Windows
- Fangs Screenreader Emulator for Firefox
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 this 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.
- Macintosh: Enabling keyboard navigation in Mac OS X Web browsers
- Firefox Keyboard Shortcuts
- Google Chrome
- Internet Explorer Keyboard Shortcuts
- Safari Shorcuts
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.