IBM Equal Access Accessibility Checker: rules, browser tooling and a CI path

What the Equal Access Toolkit automates in the Verify phase

The equal-access repository hosts the source for the IBM Equal Access Toolkit, and the part most teams meet is the Accessibility Checker. The repository description puts the scope plainly: the checker contains tools to automate accessibility checking from a browser or in a continuous development and build environment. That is the whole promise, and it is deliberately narrower than the word accessibility usually carries. Nothing here claims to judge whether a page is genuinely usable, only that a defined set of rules can be evaluated automatically.

The toolkit documentation organises its guidance into phases, Plan, Design, Develop and Verify, and the automated tools sit in the Verify phase. That placement tells you how the project wants to be used: not as a design review, but as a check that runs after the interface already exists. The repository is written in JavaScript, is not archived, and its topic list names wcag20, wcag21 and wcag22 alongside accessibility-automation and accessibility-testing, so the rules are tied to published conformance levels rather than a private house style.

How the rule engine and rule-server split the work

The repository is organised into tools and components, and the split between them matters to anyone hosting the checker on their own network. The accessibility-checker-engine directory holds the accessibility rules and the evaluation engine. The rule-server directory deploys those rules and the engine for use by the tools. So the rule set is the shared asset, and the tools are clients that draw on it.

Around that engine sit several delivery mechanisms. accessibility-checker-extension is a web developer tools browser extension that adds automated accessibility checking capabilities. accessibility-checker is the automated testing package for Node based environments, with baseline validation and local file scanning. cypress-accessibility-checker is described plainly as a wrapper of accessibility-checker for the Cypress environment.

The repository root also lists java-accessibility-checker, karma-accessibility-checker, vitest-accessibility-checker, report-react, common and a travis directory. Each of these has its own README file, and the root documentation deliberately stops there, pointing readers to the tool they have chosen instead of describing them centrally.

Building from source means a monorepo install across eight sub-packages

Building the tools yourself is a three step path, and the build requirements call for Node Version 22. First clone the repository and move into it:

$ git clone --branch=master https://github.com/IBMa/equal-access.git
$ cd equal-access

The documentation also offers an SSH form of the same clone, so pick whichever matches how your machine authenticates to GitHub. Then install dependencies from the equal-access directory:

npm install

That single command fans out. The root package.json defines an install script that runs npm-run-all across install:engine, install:report, install:rule-server, install:extension, install:accessibility-checker, install:karma-accessibility-checker, install:cypress-accessibility-checker and install:common, and each of those changes directory and installs again. Individual builds are available too, such as build:engine, build:accessibility-checker, build:rule-server and build:extension.

To build everything from the root directory, two commands are given:

$ npm install
$ npm run build

After that the engine output lands in the accessibility-checker-engine/dist directory as ace.js and ace-node.js for production use, with ace-debug.js and ace-node-debug.js for development.

Two routes into a pipeline, with different amounts of control

Most engineering decisions about this project are actually decisions about which route into continuous integration to take. The Node package, published to the npm store as accessibility-checker, is the general option. The project documentation describes it as automated accessibility testing within a continuous integration pipeline, for example Travis CI for Node based test environments, working with test frameworks such as Selenium, Puppeteer and Playwright. It also adds two capabilities that the browser side does not have: the ability to validate results against baseline files, and the ability to scan local files.

The alternative route is the Cypress wrapper, cypress-accessibility-checker. If your suite already runs in Cypress, this package is a thin wrapper rather than a separate evaluation system, so you avoid wiring an HTML parsing engine and a browser driver yourself. The difference in approach is concrete: the Node package gives you the whole checker as a library you drive, while the Cypress wrapper keeps the runner you already have and inserts the checker into it.

A third, quieter option is the rule server. The start-server:rule-server script exists in the root package.json, which suggests running the rules as a service that tools can query, the sensible route when the rule set should be updated without rebuilding every client.

The Dockerfile and the build documentation disagree about the Node version

Here is a genuine inconsistency to plan around. Node Version 22 is listed as the requirement for building the tools. The Dockerfile at the repository root pins a different runtime, setting the environment variable NODE_VERSION to 16.17.0 and downloading that Node tarball for the detected architecture. The image is based on debian:bullseye-slim and creates a node user with uid 1000, so it is a real build recipe rather than a placeholder.

Nothing in the documentation explains which version wins for a containerised build, and the root package.json reports version 3.0.0 while the published releases listed on the releases page are in the 4.0.x line, the most recent being 4.0.34. So a team that assumes the Docker image, the build instructions and the release number all describe the same state will be wrong twice over.

Practically, treat the Dockerfile as needing your own verification. Build an image, check the Node version inside it, and if you need Node 22 for the build, override the environment variable in your own Dockerfile rather than editing the repository copy. No override mechanism is documented.

Baseline files answer a narrow question and leave the rest open

The most interesting capability in the Node package is baseline validation, and it is also the most easily misunderstood. A baseline file records the results you accept at a point in time, so the checker can report differences against that recorded state instead of simply listing every violation on every run. That turns a wall of findings into a change in findings, which is what makes a check tolerable inside a pull request pipeline.

What that does not do is decide whether a violation matters. A rule that fires consistently will keep firing until someone edits the baseline, and nobody can tell from the baseline file itself whether the finding is a genuine defect or an accepted exception. Nothing in the documentation explains how baselines should be regenerated, reviewed or retired, and it does not describe a way to mark a specific finding as accepted with a reason attached.

Nor does the tooling cover the parts of accessibility that need a person. Automated rules can see missing labels, contrast values and structural problems, but they cannot tell you whether a form error message makes sense, or whether a page works with a screen reader. Manual testing is not documented, so if your compliance process expects the checker output to stand in for a manual review, that expectation is unsupported by the documentation.

Apache-2.0 terms and a project that is still moving

The repository is published under the Apache-2.0 licence, and the LICENSE file sits at the root. That is a permissive licence with an explicit patent grant, which suits commercial use and modification, although the repository does not include a patent or trademark policy beyond the standard text, so how the IBM name may be used in your tooling is a question for your own counsel rather than something the files answer.

On maintenance, the facts are favourable but worth stating precisely. The repository is not archived, and the last push was on 2026-10-16. The recent release history shows three publishes inside a single week: 4.0.32 and 4.0.33 on 2026-09-03, and 4.0.34 on 2026-09-08. Recent work is therefore in the rule set and the deployed tools rather than in a new architecture. The upgrade cost for a team that has adopted the Node package is a version bump and a fresh baseline review, and the release notes are published on the releases page rather than in the repository, so you will need to read them before each bump.

Editorial conclusion

equal-access makes sense for teams that want one rule set running in developer tools and in a pipeline, and for organisations that need to host the rule server themselves. It is the wrong choice for a team expecting the tools to catch accessibility problems that only a human can judge, or one unwilling to maintain a JavaScript monorepo and its rule server. Before adopting, check the Node version your build image actually has, because the project documentation asks for Node 22 while the bundled Dockerfile pins 16.17.0, and read how your chosen runner consumes the rule server before you wire it into a continuous integration job.

Frequently asked questions

Official sources

1. IBMa/equal-access on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases