Coding for accessibility made easy.
- Checks React (.js .jsx .ts .tsx), Vue (.vue), Angular (.component.html), HTML (.html .htm), and Markdown (.md .markdown) files so you can avoid common accessibility defects. Inline Angular templates are not currently supported.
- Consistent with the open-source axe-core rules engine to provide early warnings of real accessibility defects -- zero false positives, so you don't have to write a bunch of
- No configuration required -- zero learning curve, so you can be productive immediately.
- Shareable project-specific configurations, so your team can select the accessibility standard and select individual rules.
Once you’ve nailed catching accessibility issues in your source code, try expanding your test coverage by testing in the browser with the free axe browser extension.
Once the plugin is installed, axe-linter installs and configures itself automatically. This can sometimes take a few minutes. Once this step is completed, axe-inter will start running on compatible source files.
axe-linter has the following rules:
The following tags are available for configuration in axe-linter:
||Accessibility Standard / Purpose
|WCAG 2.0 Level A
|WCAG 2.0 Level AA
|WCAG 2.1 Level A
|WCAG 2.1 Level AA
|Common accessibility best practices
The rules axe-linter uses are configurable by adding a file called
axe-linter.yml at your project's root level.
There are two options for rule configuration. You can enable/disable rules at the individual level with the
some-rule: false # turn off rule
other-rule: true # turn on rule
You can also disable rules as a group based on WCAG standard they are associated with using the
tags: # Disable all rules for WCAG 2.0 and 2.1, level A and level AA
Axe-linter gathers a minimal amount of telemetry in order to assist in monitoring the plugin's heartbeat. The collected data is limited to the date and time of scans, the axe-linter engine version, and identification of the data as being axe-linter related. The data points it gathers are as follows: