-
Notifications
You must be signed in to change notification settings - Fork 85
Home
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
The Checker is available as a browser development tools (DevTools) extension from the following stores:
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:
- 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
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 once and then repeatedly scan the same set of pages or files.
In addition to using your browser’s DevTools 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:
- Create a .txt file with a path to files, directories, or a list of URLs to be scanned need link to boilerplate .txt file example
- Provide the npx achecker command the full path to your .txt file to be able to run the scan
- e.g.,
npx achecker path/to/your/file.txt - e.g., run from a macOS or VSCode terminal
- e.g.,
- Run
npx achecker
- 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.
-
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.
- Get and use a crawler to create a set of pages automatically or manually create a list of URLs to be scanned
- Install NodeJS and NPM (new to NPM? read about the NodeJS ecosystem)
By using a boilerplate, developers can focus on the unique aspects of their project rather than building automated accessibility testing in their pipeline from scratch.
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:
- A scan was run that detected some issues.
- Some of the issues are resolved or identified to be fixed later.
- The next scan was run to detect the remaining previously known issues.
- The scan results are saved as a baseline of known issues.
- 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:
- See the Development notes, such as key files, extension architecture, and other resources.
- IBM Equal Access Toolkit - guidance for product managers, designers, developers, and testers.
- Alto Mutual - a sample banking web app for demonstration and testing.
- Checker's implementation of ACT rules.
- Submit a Git issue
- Quick guide (available to users once installed)
- User guide more in-depth (available to users once installed)
- Internal IBM - Slack channel #accessibility-at-ibm provides internal support
- Private IBM - Squad channel #ibma-squad-2 for squad discussions