Skip to content

Home

Jump to bottom
Phill Jenkins edited this page Apr 17, 2025 · 51 revisions

Welcome to the equal-access Wiki

About

The IBM Equal Access Accessibility Checker is an open-source freely available set of tools for web developers and accessibility auditors. The accessibility-checker-engine utilizes a set of rules that map to accessibility standards to detect accessibility issues in web content and applications. The accessibility-checker-extension integrates into browser DevTools, providing an integrated scanning experience, a keyboard checker mode visualization, and helps users quickly identify the source of accessibility issues, understand what to do, and try fixes. The Checker is also available as a package for CI/CD environments and automated testing frameworks.

The Checker does not collect or send your web data to any servers:

  • all your web data is kept local
  • the rules and engine are downloaded and run locally
  • no data is being used, sold, or transferred to 3rd parties

Extensions

The Checker is available as a browser development tools (DevTools) extension from the following stores:

How-to Videos

  • Intro video - An introduction to the browser web developer tools extension and how to install it
  • Focus view video - A demo of the ‘Focus view’ feature for unit testing
  • Create reports video - A demo of how to create reports and scan multiple pages

Packages for test automation

Packages are available for integrating into your Continuous Integrations/Continuous Development (CI/CD) environments, such as Node Package Manager NPM for JavaScript environments and testing frameworks (parsing engines) such as Selenium, Puppeteer, Playwright, and Zombie:

Automated testing in your pipeline

By using a boilerplate, Node developers can focus on the unique aspects of their project rather than building automated accessibility testing in their pipeline from scratch.

Baseline basics

Aside from just performing accessibility scanning, the packages provide a framework to validate accessibility scan results against baseline files and/or simply failing their test cases based on the levels of violations found during the scan.

Setting up a baseline:

  1. A scan was run that detected some issues.
  2. Some of the issues are resolved or identified to be fixed later.
  3. The next scan was run to detect the remaining previously known issues.
  4. The scan results are saved as a baseline of known issues.
  5. Future scans may ignore the known issues stored in the baseline and/or pause the development process because of newly introduced issues detected.

The baseline feature allows a team to snapshot where they're at to prevent new issues from being introduced. This also allows a team to fail on potential violations or Needs review issues, but then continue their development process because they have stored those issues in the baseline. The baseline issues were assessed and determined they were resolved or identified to be fixed later.

See the following examples of validating automated accessibility testing results against stored baseline files:

Scanning multiple pages

You might want to simply scan a set of pages. The Checker provides several approaches that will fit your environment and ecosystem to scan a set of pages, repeatedly scan the same set of pages or files, and compare results.

Browser extension multi-scan

Start storing scans automatically to combine up to 50 scans into a single Microsoft Excel XLS spreadsheet report. The multi-scan report identifies common issues across pages and states.

You can use your browser’s DevTools Checker extension to manually scan and store each scan report. Checker users scan after navigating through their web pages or application, changing dynamic content with end-user input or scripting, and after loading additional pages. Remember to Start storing scans automatically and press the Scan button on each desired state of the page(s). The details include the Type of issue, such as Violation, Needs review, or Recommendation, and a robust listing the WCAG Success Criteria, Element, Xpath, Toolkit's Pace of progression level, and a link to Help to learn What to do. See the User guide, link when installed in Chrome: chrome-extension://jjfgfnmpbokgcdcjjfdifcelbhenfpbm/usingAC.html#t_multi_scan_report.

Command-line multi-scan

In addition to using your browser’s Checker extension and manually scanning and storing each scan report, another way to scan multiple pages is via a command-line approach. The accessibility-checker module provides a basic command-line utility that will allow scanning files, directories, and a list of URLs:

  1. Create a .txt file with a path to files, directories, or a list of URLs to be scanned. This list could be the output generated by your favorite crawler.
  2. Provide the npx achecker command the full path to your .txt file
    • e.g., npx achecker path/to/your/file.txt
  3. Run npx achecker
    • e.g., run from a macOS or VSCode terminal

Pro tip:

  • To install and run npx, you don't need to install it separately as it comes bundled with NPM; simply install the latest version of Node.js, which includes npm and npx.
  • batch-scan: To repeatedly scan a list of local .html files, see the batch-scan boilerplate in the repo as another approach.

How to use Command-line multi-scan:

  • Run: to run a command with npx, type npx <package-name> <arguments> in your terminal (e.g. macOS or VSCode).
  • Functionality: npx allows you to execute commands from npm packages without needing to install them globally.
  • Output: set your configuration to specify the format of your results.

Prerequisites for Command-line multi-scan

  1. Get and use a crawler to create a set of pages automatically or manually create a list of URLs to be scanned
  2. Install NodeJS and NPM (new to NPM? read about the NodeJS ecosystem)

Resources

Support

This is a custom h3 footer

with option to add content here too

Table of contents

Development Notes

W3C ACT Implementation

Clone this wiki locally