Chisle
The coding-agent plugin that bills 52% of a bare model across 20 live tasks. Terse persona + tool-output compressor + context diet.
翻訳待ち
Accessibility engine for automated Web UI testing
翻訳待ち
Loading the full README.
Read the full README ↗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 be 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:
npm install axe-core --save-dev
Or, using pnpm:
pnpm add --save-dev axe-core
Now include the javascript file in each of your iframes in your fixtures or test systems:
<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:
axe
.run()
.then(results => {
if (results.violations.length) {
throw new Error('Accessibility issues found');
}
})
.catch(err => {
console.error('Something bad happened:', err.message);
});
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 fileThis is the beginning of the README. Read the rest at the original. Read the full README ↗