axe-core

Axe-core tests for accessibility using a hierarchy of Rules and Checks.

• Rules: High-level accessibility aspects (e.g., color contrast, button labels). A Rule consists of one or more Checks. A Rule passes if its required Checks pass (based on any, all, or none logic).
• Checks: The granular tests that perform the actual evaluation. A Check returns true, false, or undefined.

Rules are defined in JSON files in lib/rules and Checks in lib/checks.

Use the built-in script to help generate rule files. Ensure dependencies are installed first.

npm install
npm run rule-gen

To ensure high-quality rules and clear error reporting, follow these design principles:

1. Single none check: Rules should ideally only have one none check to ensure the resulting error message is specific and actionable.
2. Avoid mixing check types: Do not combine any and none check types within a single rule; instead, break them out into separate rules.
3. Atomic checks: Each check should test only a single specific case (either one passing technique or one failing test condition).
4. Simplicity: When describing check logic in a proposal, use short, high-level sentences rather than exhaustive logic.

axe-core assigns an impact level to each accessibility issue based on the likely effect on users with disabilities. While these levels provide a baseline, users should evaluate each issue within the specific context of their application, as actual impact may be higher or lower.

Impact levels are categorized into four tiers: Minor, Moderate, Serious, and Critical. For a complete mapping of specific rules to their assigned impacts, refer to the rule-descriptions.md documentation.

To avoid merge messages in the commit log, ensure your branch is up to date with develop by rebasing before submitting a pull request.

If you have already pushed changes to your branch, use the following commands to rebase against origin/develop:

git checkout your-branch
git fetch
git rebase origin/develop
git push origin head -f

When using axe.finishRun, the execution happens outside the original page context. Consequently, reporter and after methods do not have access to the top-level window or document objects and may lack access to common browser APIs.

Requirements for Custom Logic:

• Do not rely on browser APIs or globals.
• Use the environmentData property (available on the partialResult object of the initiator) to access necessary environment information.
• Alternatively, collect data within an evaluate method of a check and store it using the .data() method.

To create a custom build of axe-core with a specific language, use the --lang flag with the build command. You can also build all localized versions or a specific list of languages.

• Build a single language: npm run build -- --lang=<langcode> (e.g., npm run build -- --lang=nl)
• Build multiple specific languages: npm run build -- --lang=nl,ja
• Build all localized versions: npm run build -- --all-lang

Localized builds will be named axe.<lang>.js and axe.<lang>.min.js.