Gathering detailed insights and metrics for axe-core
Gathering detailed insights and metrics for axe-core
Gathering detailed insights and metrics for axe-core
Gathering detailed insights and metrics for axe-core
Accessibility engine for automated Web UI testing
npm install axe-core
99
Supply Chain
100
Quality
98.3
Maintenance
100
Vulnerability
80.9
License
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
6,027 Stars
5,176 Commits
784 Forks
173 Watching
69 Branches
230 Contributors
Updated on 27 Nov 2024
Minified
Minified + Gzipped
JavaScript (89.11%)
HTML (10.52%)
TypeScript (0.29%)
CSS (0.05%)
Shell (0.04%)
Cumulative downloads
Total Downloads
Last day
-8.2%
3,171,027
Compared to previous day
Last week
1.9%
18,263,595
Compared to previous week
Last month
5.9%
77,323,067
Compared to previous month
Last year
21.7%
833,853,463
Compared to previous year
69
Axe is an accessibility testing engine for websites and other HTML-based user interfaces. It's fast, secure, lightweight, and was built to seamlessly integrate with any existing test environment so you can automate accessibility testing alongside your regular functional testing.
Sign up for axe news to get the latest on axe features, future releases, and events.
Axe-core has different types of rules, for WCAG 2.0, 2.1, 2.2 on level A, AA and AAA as well as a number of best practices that help you identify common accessibility practices like ensuring every page has an h1
heading, and to help you avoid "gotchas" in ARIA like where an ARIA attribute you used will get ignored. The complete list of rules, grouped WCAG level and best practice, can found in doc/rule-descriptions.md.
With axe-core, you can find on average 57% of WCAG issues automatically. Additionally, axe-core will return elements as "incomplete" where axe-core could not be certain, and manual review is needed.
To catch bugs earlier in the development cycle we recommend using the axe-linter vscode extension. To improve test coverage even further we recommend the intelligent guided tests in the axe Extension.
First download the package:
1npm install axe-core --save-dev
Now include the javascript file in each of your iframes in your fixtures or test systems:
1<script src="node_modules/axe-core/axe.min.js"></script>
Now insert calls at each point in your tests where a new piece of UI becomes visible or exposed:
1axe 2 .run() 3 .then(results => { 4 if (results.violations.length) { 5 throw new Error('Accessibility issues found'); 6 } 7 }) 8 .catch(err => { 9 console.error('Something bad happened:', err.message); 10 });
The web can only become an accessible, inclusive space if developers are empowered to take responsibility for accessibility testing and accessible coding practices.
Automated accessibility testing is a huge timesaver, it doesn't require special expertise, and it allows teams to focus expert resources on the accessibility issues that really need them. Unfortunately, most accessibility tools are meant to be run on sites and applications that have reached the end of the development process and often don't give clear or consistent results, causing frustration and delays just when you thought your product was ready to ship.
Axe was built to reflect how web development actually works. It works with all modern browsers, tools, and testing environments a dev team might use. With axe, accessibility testing can be performed as part of your unit testing, integration testing, browser testing, and any other functional testing your team already performs on a day-to-day basis. Building accessibility testing into the early development process saves time, resources, and all kinds of frustration.
The axe-core API fully supports the following browsers:
Support means that we will fix bugs and attempt to test each browser regularly. Only Chrome and Firefox are currently tested on every pull request.
There is limited support for JSDOM. We will attempt to make all rules compatible with JSDOM but where this is not possible, we recommend turning those rules off. Currently the color-contrast
rule is known not to work with JSDOM.
We can only support environments where features are either natively supported or polyfilled correctly. We do not support the deprecated v0 Shadow DOM implementation.
The axe-core API package consists of:
axe.js
- the JavaScript file that should be included in your web site under test (API)axe.min.js
- a minified version of the above fileAxe can be built using your local language. To do so, a localization file must be added to the ./locales
directory. This file must be named in the following manner: <langcode>.json
. To build axe using this locale, instead of the default, run axe with the --lang
flag, like so:
grunt build --lang=nl
or equivalently:
npm run build -- --lang=nl
This will create a new build for axe, called axe.<lang>.js
and axe.<lang>.min.js
. If you want to build all localized versions, simply pass in --all-lang
instead. If you want to build multiple localized versions (but not all of them), you can pass in a comma-separated list of languages to the --lang
flag, like --lang=nl,ja
.
To create a new translation for axe, start by running grunt translate --lang=<langcode>
. This will create a json file in the ./locales
directory, with the default English text in it for you to translate. Alternatively, you could copy ./locales/_template.json
. We welcome any localization for axe-core. For details on how to contribute, see the Contributing section below. For details on the message syntax, see Check Message Template.
To update an existing translation file, re-run grunt translate --lang=<langcode>
. This will add new messages used in English and remove messages which were not used in English.
Additionally, locale can be applied at runtime by passing a locale
object to axe.configure()
. The locale object must be of the same shape as existing locales in the ./locales
directory. For example:
1axe.configure({ 2 locale: { 3 lang: 'de', 4 rules: { 5 accesskeys: { 6 help: 'Der Wert des accesskey-Attributes muss einzigartig sein.' 7 } 8 // ... 9 }, 10 checks: { 11 abstractrole: { 12 fail: 'Abstrakte ARIA-Rollen dürfen nicht direkt verwendet werden.' 13 }, 14 'aria-errormessage': { 15 // Note: doT (https://github.com/olado/dot) templates are supported here. 16 fail: 'Der Wert der aria-errormessage ${data.values}` muss eine Technik verwenden, um die Message anzukündigen (z. B., aria-live, aria-describedby, role=alert, etc.).' 17 } 18 // ... 19 } 20 } 21});
Axe-core supports the following locales. Do note that since locales are contributed by our community, they are not guaranteed to include all translations needed in a release.
Axe-core has a new minor release every 3 to 5 months, which usually introduces new rules and features. We recommend scheduling time to upgrade to these versions. Security updates will be made available for minor version lines up to 18 months old.
DEQUE, DEQUELABS, AXE®, and AXE-CORE® are trademarks of Deque Systems, Inc. Use of the Deque trademarks must be in accordance with Deque's trademark policy.
Refer axe-core ARIA support for a complete list of ARIA supported roles and attributes by axe.
Read the Proposing Axe-core Rules guide
Read the documentation on the architecture
Read the documentation on contributing
List of projects using axe-core
Thanks to Marat Dulin for his css-selector-parser implementation which is included for shadow DOM support. Another thank you to the Slick Parser implementers for their contribution, we have used some of their algorithms in our shadow DOM support code. Thanks to Lea Verou and Chris Lilley for their colorjs.io library which we have used for converting between color formats.
Axe-core is distributed under the Mozilla Public License, version 2.0. It comes bundled with several dependencies which are distributed under their own terms. (See LICENSE-3RD-PARTY.txt)
No vulnerabilities found.
Reason
30 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Reason
all changesets reviewed
Reason
security policy file detected
Details
Reason
no dangerous workflow patterns detected
Reason
license file detected
Details
Reason
no binaries found in the repo
Reason
dependency not pinned by hash detected -- score normalized to 5
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
10 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More