Checking Web Page Accessibility with WebAIM WAVE

Summary

Summary

This article will describe how to review a web page for accessibility using the WebAIM WAVE automated accessibility checker. It includes general caveats on automated testing and links to resources that can improve ability to manually review web and office documents for accessibility.

This article is limited to WAVE. Other articles will be added to cover other tools, and linked as related documents.

Specific actions to address problems are out of scope for this article. To learn how to address specific issues, we suggest consulting training/reference materials at Deque University. (Learn how to get access.)

This is a living document. It will be updated and expanded to improve coverage of the subject.

What is WebAIM WAVE?

WAVE is a browser-based tool to assess a web page’s conformance with WCAG (Web Content Advisory Group) accessibility recommendations. Currently it evaluates against WCAG 2.2, which is the standard to which GCC is required to conform by NYS. (See Accessibility of Information Communication [NYS-P08-005] (PDF).)

Limitations of WAVE

• WAVE is an automated tool, and as such it can only assess letter-of-the-law conformance. Since it’s possible to produce web pages that are fully conformant with the current WCAG version and which nevertheless fail to be accessible to some communities or persons, it’s important to also perform a manual review. (See ‘Resources for Manual Testing’, below.)
• WAVE can only evaluate pages that are accessible on the public internet without a password. For example, it cannot evaluate pages in myGCC or Brightspace.
• WAVE can only evaluate HTML web pages. Web pages or parts of web pages that aren’t rendered as HTML, such as PDF documents, other kinds of documents viewed using a browser-based viewer, or user interfaces rendered by some non-HTML technology, cannot be evaluated by WAVE.
• Similarly, even some HTML pages are too complex to be usefully evaluated using WAVE.

How to Access WAVE

WAVE can be used in two ways:

• Submitting a URL for evaluation using WebAIM’s online tool.
• Evaluating pages in situ using the WAVE browser plugin (available for Chrome, Firefox, & Edge).
  • Chrome plugin is available from the Google Play Store
  • Firefox extension is available from the Mozilla extension repository
  • Edge plugin available from the Edge Add-Ons repository

Differences between online and browser plugin version

Advantages of the browser plugin:

• Convenience –no need to browse to a remote website and paste a URL.
• Integrates more closely with the Chrome or Firefox ‘inspector’ tool.

Advantages of the online tool:

• Can be used from any browser or operating environment (e.g. from Safari on MacOS or iOS, or a non-Chromium/non-Mozilla browser).
• Can be used on an unfamiliar system, or one that does not have the browser plugin installed (e.g. a lab, library, or classroom computer).

How to Use WAVE

Most GCC users

Web-based tool

1. Go to wave.webaim.org and type in (or cut and paste) the URL you want to check.
   
2. Click the arrow   to start an accessibility check.
3. Once the tool has completed its check, it will display a summary of Errors, Alerts, Features, etc. as a box on the left side of the browser window:
   
4. Proceed to step 3 in the next section (‘Browser plugin’): Once you are viewing the results, the web-based tool is functionally identical to the browser-based tool.

Browser plugin

1. While browsing a web page, click the WAVE extension icon to evaluate the current page.
2. Once the tool has completed its check, it will display a summary of Errors, Alerts, Features, etc. as a box on the left side of the browser window:
   
3. NOTE: WAVE does not require that you review or address issues in a specific order. Steps 4 through x below can be approached in any order you find useful.
4. Review Details, either by clicking the Details tab, or the ‘View Details’ button. Icons that are pale relative to icons of the same color (for example,  versus ) are not visible without some action on the user’s part.
   
   Details are reported in the same order in which they were displayed on the Summary screen:
   1. Errors: issues which could prevent some users from accessing content.
      To review errors, work through the following for each error
      1. Click on the icon each identified error
      2. Find the corresponding icon in the page, to the left of the side panel. It will be highlighted using a dotted red border.
   2. Contrast Errors: Color contrast that’s insufficient for users who are colorblind or have some types of low vision. (Reported separately because they’re so common.) You can find additional detail and a tool to help you understand the contrast issue on the Contrast tab.
   3. Alerts: Issues which could make content more difficult to read or understand.
   4. Features: Elements about which there’s a rule, that don’t fit into another category. You can generally ignore these unless you need help figuring out how to address a problem that you identified via manual review.
   5. Structural Elements: Lists all the structural elements that have been recognized on the page, including headings, lists, and landmarked navigation or search elements. Use these to determine whether things are being identified as navigation that should be, that the hierarchy of headings is what you wanted, and that all the elements noted have the names they should have.
   6. ARIA (Accessible Rich Internet Applications): Can be ignored by most users at GCC. ARIA features are advanced and are more often mis-used than used properly. The Web Accessibility Initiative (authors of the ARIA specification) has remarked that ‘no ARIA is better than bad ARIA.’ If you are creating the page yourself and have doubt about your ARIA, the best practice is to find another way to do what you’re trying to do. The WCAG specifications include reference code that can be helpful for this.
5. Reference. Click on one of the WAVE-generated icons superimposed on the page to better understand the issue being described.
6. Order. Displays the ‘tab order’ (the order in which elements will be highlighted if you press the Tab key) of linked elements on the page. You can use this to quickly see if some linked page element will be out of order for people who have no or very limited ability to use a mouse.
7. Structure. Similar to ‘Structural Elements’, but organized a little differently. This view is better for getting a feel whether the semantic structure of your page is what you intended.
8. Contrast. Lists all color contrast errors, and provides a tool to help you find colors that will provide sufficient contrast. The ‘Desaturate Page’ tool can be particularly useful to help understand the impact of color contrast on accessibility.

Warnings about Automated Testing

Automated testing tools such as WAVE can only evaluate quantitatively – that is, does the website conform to specific criteria. But accessibility is qualitative: Is the resource being made equitably available?

Put another way, it’s possible for a web page or a document to be fully conformant with WCAG, and yet not accessible.

Similarly, a resource could be non-conformant, but still be satisfactorily accessible.

For example, it’s quite common for web page elements to show up as very low contrast, when the visual contrast is actually fine, because the conformant contrast is created by web code that’s too complex for WAVE to parse.

Some vendors (such as Deque) are continually developing machine learning (“AI”) tools to improve automated testing; however, at this time, there are no reliable machine learning tools that can eliminate the need for manual testing, and no reputable vendor is forecasting the availability of such tools in the foreseeable future.

Resources for Manual Testing

We recommend requesting access through SUNY to Deque University, and familiarizing yourself with the training and reference materials they make available.