accessibility-developer-tools
This is a library of accessibility-related testing and utility code.
Top Related Projects
Accessibility engine for automated Web UI testing
Pa11y is your automated accessibility testing pal
WAI-ARIA Authoring Practices Guide (APG)
Automated auditing, performance metrics, and best practices for the web.
Quick Overview
Accessibility Developer Tools is a library of accessibility-related testing and utility code created by Google Chrome. It provides a collection of audit rules and utilities to help developers evaluate and improve the accessibility of web content, focusing on compliance with Web Content Accessibility Guidelines (WCAG) and other best practices.
Pros
- Comprehensive set of accessibility audit rules
- Easy integration with existing testing frameworks
- Actively maintained by Google Chrome team
- Helps developers identify and fix accessibility issues early in the development process
Cons
- Limited to static analysis, may not catch all dynamic content issues
- Requires some knowledge of accessibility principles to interpret results effectively
- May produce false positives in certain complex scenarios
- Documentation could be more extensive for some advanced features
Code Examples
- Running an accessibility audit:
var auditConfig = new axs.AuditConfiguration();
var results = axs.Audit.run(auditConfig);
console.log(results);
- Checking a specific element for accessibility issues:
var element = document.getElementById('myElement');
var result = axs.Audit.run({scope: element});
console.log(result);
- Creating a custom audit rule:
axs.AuditRules.addRule({
name: 'myCustomRule',
severity: axs.constants.Severity.WARNING,
relevantNodesSelector: function() {
return document.querySelectorAll('button');
},
test: function(button) {
return button.textContent.length > 0;
},
code: 'AX_BUTTON_NAME'
});
Getting Started
To use Accessibility Developer Tools in your project:
-
Install the library via npm:
npm install accessibility-developer-tools
-
Include the library in your HTML:
<script src="node_modules/accessibility-developer-tools/dist/js/axs_testing.js"></script>
-
Run an accessibility audit:
var results = axs.Audit.run(); console.log(axs.Audit.createReport(results));
This will output a report of accessibility issues found on the page.
Competitor Comparisons
Accessibility engine for automated Web UI testing
Pros of axe-core
- More actively maintained with frequent updates
- Larger community and wider adoption in the industry
- Extensive documentation and better support resources
Cons of axe-core
- Steeper learning curve for beginners
- Larger file size, which may impact performance in some cases
Code Comparison
accessibility-developer-tools:
axs.Audit.run({
scope: document,
rules: ['badAriaRole', 'controlsWithoutLabel']
});
axe-core:
axe.run().then(results => {
console.log(results.violations);
});
Both libraries offer accessibility testing capabilities, but axe-core provides a more modern and promise-based API. accessibility-developer-tools allows for more granular control over which rules to run, while axe-core offers a simpler interface for running all checks at once.
axe-core has gained significant traction in the accessibility testing community due to its comprehensive rule set and regular updates. However, accessibility-developer-tools may still be preferred in certain scenarios where a lighter-weight solution is needed or when working with older codebases.
Ultimately, the choice between these two libraries depends on project requirements, team expertise, and specific accessibility testing needs.
Pa11y is your automated accessibility testing pal
Pros of pa11y
- Command-line interface for easy integration into CI/CD pipelines
- Supports multiple output formats (JSON, CSV, HTML)
- Extensible through custom rules and reporters
Cons of pa11y
- Limited to static analysis of web pages
- Requires Node.js environment to run
- Less comprehensive than browser-based tools for dynamic content testing
Code comparison
pa11y:
const pa11y = require('pa11y');
pa11y('https://example.com').then((results) => {
console.log(results);
});
accessibility-developer-tools:
chrome.accessibilityAudit.addRule({
name: 'myCustomRule',
severity: 'Warning',
relevantNodesSelector: 'button',
test: function(node) {
return node.textContent.trim().length > 0;
}
});
Key differences
- pa11y is a standalone tool, while accessibility-developer-tools is a Chrome extension
- accessibility-developer-tools provides a more interactive experience within the browser
- pa11y focuses on automated testing, while accessibility-developer-tools offers real-time feedback during development
Use cases
- pa11y: Continuous integration, automated accessibility checks
- accessibility-developer-tools: In-browser development, manual testing, and debugging
Both tools contribute to improving web accessibility, but they serve different purposes in the development workflow.
WAI-ARIA Authoring Practices Guide (APG)
Pros of aria-practices
- Comprehensive documentation and examples for ARIA implementation
- Regularly updated to reflect latest W3C standards and best practices
- Collaborative effort with input from accessibility experts worldwide
Cons of aria-practices
- Primarily focused on ARIA, less coverage of other accessibility aspects
- Can be overwhelming for beginners due to extensive technical details
- Lacks automated testing tools or browser integration
Code Comparison
aria-practices example (ARIA Accordion):
<div role="region" aria-labelledby="accordion-heading">
<h3 id="accordion-heading">Accordion Example</h3>
<div role="button" aria-expanded="false" aria-controls="section1">
Section 1
</div>
<div id="section1" role="region" aria-labelledby="section1-heading">
<h4 id="section1-heading">Section 1 Content</h4>
<!-- Content here -->
</div>
</div>
accessibility-developer-tools example (Audit Rule):
axs.AuditRules.addRule({
name: 'imageWithoutAltText',
severity: axs.constants.Severity.SEVERE,
relevantElementMatcher: function(element) {
return axs.utils.isElementWithRole(element, 'img') && !element.hasAttribute('alt');
},
test: function(element) {
return false;
},
code: 'AX_TEXT_01'
});
Automated auditing, performance metrics, and best practices for the web.
Pros of Lighthouse
- More comprehensive analysis, covering performance, accessibility, SEO, and best practices
- Actively maintained with regular updates and new features
- Integrated into Chrome DevTools for easy access
Cons of Lighthouse
- Larger codebase and more complex setup for local development
- May be overkill for projects focused solely on accessibility testing
- Potentially slower execution due to broader scope of analysis
Code Comparison
accessibility-developer-tools:
axs.Audit.run = function(options) {
var results = [];
for (var i = 0; i < this.auditRules.length; i++) {
var rule = this.auditRules[i];
results.push(rule.run(options));
}
return results;
};
Lighthouse:
async function runLighthouse(url, opts, config = null) {
const results = await lighthouse(url, opts, config);
const reportHtml = results.report;
const reportJson = JSON.parse(results.report);
return { reportHtml, reportJson };
}
The code snippets show that accessibility-developer-tools focuses specifically on accessibility audits, while Lighthouse provides a more comprehensive analysis with a broader range of metrics and reporting options.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Accessibility Developer Tools
This is a library of accessibility-related testing and utility code.
Its main component is the accessibility audit: a collection of audit rules checking for common accessibility problems, and an API for running these rules in an HTML page.
There is also a collection of accessibility-related utility code, including but not limited to:
- contrast ratio calculation and color suggestions
- retrieving and validating ARIA attributes and states
- accessible name calculation using the algorithm at http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
Getting the code
To include just the javascript rules, require the following file:
https://raw.github.com/GoogleChrome/accessibility-developer-tools/stable/dist/js/axs_testing.js
git 1.6.5
or later:
% git clone --recursive https://github.com/GoogleChrome/accessibility-developer-tools.git
Before git 1.6.5
:
% git clone https://github.com/GoogleChrome/accessibility-developer-tools.git
% cd accessibility-developer-tools
% git submodule init; git submodule update
Building
You will need node
and grunt-cli
to build.
-
(Once only) Install Node.js and
npm
- useful instructions here: https://gist.github.com/isaacs/579814Make sure you have Node.js v 0.8 or higher.
-
(Once only) Use
npm
to installgrunt-cli
% npm install -g grunt-cli # May need to be run as root
-
(Every time you make a fresh checkout) Install dependencies (including
grunt
) for this project (run from project root)% npm install
-
(Rebuild if you make changes) Build using
grunt
(run from project root)% grunt
Troubleshooting
This project uses Closure Compiler to build our releases. You may need to install a recent version of JDK in order for builds to successfully complete.
Using the Audit API
Including the library
The simplest option is to include the generated axs_testing.js
library on your page. After you build, you will have two versions of axs_testings.js
:
- Distribution Build: project-root/dist/js/axs_testing.js
- Local Build (use if you make changes): project-root/tmp/build/axs_testing.js
Work is underway to include the library in WebDriver and other automated testing frameworks.
The axs.Audit.run()
method
Once you have included axs_testing.js
, you can call axs.Audit.run()
. This returns an object in the following form:
{
/** @type {axs.constants.AuditResult} */
result, // one of PASS, FAIL or NA
/** @type {Array.<Element>} */
elements, // The elements which the rule fails on, if result == axs.constants.AuditResult.FAIL
/** @type {axs.AuditRule} */
rule // The rule which this result is for.
}
Command Line Runner
The Accessibility Developer Tools project includes a command line runner for the audit. To use the runner, install phantomjs then run the following command from the project root directory.
$ phantomjs tools/runner/audit.js <url-or-filepath>
The runner will load the specified file or URL in a headless browser, inject axs_testing.js, run the audit and output the report text.
Run audit from Selenium WebDriver (Scala):
val driver = org.openqa.selenium.firefox.FirefoxDriver //use driver of your choice
val jse = driver.asInstanceOf[JavascriptExecutor]
jse.executeScript(scala.io.Source.fromURL("https://raw.githubusercontent.com/GoogleChrome/" +
"accessibility-developer-tools/stable/dist/js/axs_testing.js").mkString)
val report = jse.executeScript("var results = axs.Audit.run();return axs.Audit.createReport(results);")
println(report)
Run audit from Selenium WebDriver (Scala)(with caching):
val cache = collection.mutable.Map[String, String]()
val driver = org.openqa.selenium.firefox.FirefoxDriver //use driver of your choice
val jse = driver.asInstanceOf[JavascriptExecutor]
def getUrlSource(arg: String): String = cache get arg match {
case Some(result) => result
case None =>
val result: String = scala.io.Source.fromURL(arg).mkString
cache(arg) = result
result
}
jse.executeScript(getUrlSource("https://raw.githubusercontent.com/GoogleChrome/" +
"accessibility-developer-tools/stable/dist/js/axs_testing.js"))
val report = js.executeScript("var results = axs.Audit.run();return axs.Audit.createReport(results);")
println(report)
If println() outputs nothing, check if you need to set DesiredCapabilities for your WebDriver (such as loggingPrefs): https://code.google.com/p/selenium/wiki/DesiredCapabilities
Using the results
Interpreting the result
The result may be one of three constants:
axs.constants.AuditResult.PASS
- This implies that there were elements on the page that may potentially have failed this audit rule, but they passed. Congratulations!axs.constants.AuditResult.NA
- This implies that there were no elements on the page that may potentially have failed this audit rule. For example, an audit rule that checks video elements for subtitles would return this result if there were no video elements on the page.axs.constants.AuditResult.FAIL
- This implies that there were elements on the page that did not pass this audit rule. This is the only result you will probably be interested in.
Creating a useful error message
The static, global axs.Audit.createReport(results, opt_url)
may be used to create an error message using the return value of axs.Audit.run(). This will look like the following:
*** Begin accessibility audit results ***
An accessibility audit found 4 errors and 4 warnings on this page.
For more information, please see https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules
Error: badAriaAttributeValue (AX_ARIA_04) failed on the following elements (1 - 3 of 3):
DIV:nth-of-type(3) > INPUT
DIV:nth-of-type(5) > INPUT
#aria-invalid
Error: badAriaRole (AX_ARIA_01) failed on the following element:
DIV:nth-of-type(11) > SPAN
Error: controlsWithoutLabel (AX_TEXT_01) failed on the following elements (1 - 3 of 3):
DIV > INPUT
DIV:nth-of-type(12) > DIV:nth-of-type(3) > INPUT
LABEL > INPUT
Error: requiredAriaAttributeMissing (AX_ARIA_03) failed on the following element:
DIV:nth-of-type(13) > DIV:nth-of-type(11) > DIV
Warning: focusableElementNotVisibleAndNotAriaHidden (AX_FOCUS_01) failed on the following element:
#notariahidden
Warning: imagesWithoutAltText (AX_TEXT_02) failed on the following elements (1 - 2 of 2):
#deceptive-img
DIV:nth-of-type(13) > IMG
Warning: lowContrastElements (AX_COLOR_01) failed on the following elements (1 - 2 of 2):
DIV:nth-of-type(13) > DIV
DIV:nth-of-type(13) > DIV:nth-of-type(3)
Warning: nonExistentAriaLabelledbyElement (AX_ARIA_02) failed on the following elements (1 - 2 of 2):
DIV:nth-of-type(3) > INPUT
DIV:nth-of-type(5) > INPUT
*** End accessibility audit results ***
Each rule will have at most five elements listed as failures, in the form of a unique query selector for each element.
Configuring the Audit
If you wish to fine-tune the audit, you can create an axs.AuditConfiguration
object, with the following options:
Ignore parts of the page for a particular audit rule
For example, say you have a separate high-contrast version of your page, and there is a CSS rule which causes certain elements (with class pretty
) on the page to be low-contrast for stylistic reasons. Running the audit unmodified produces results something like
Warning: lowContrastElements (AX_COLOR_01) failed on the following elements (1 - 5 of 15):
...
You can modify the audit to ignore the elements which are known and intended to have low contrast like this:
var configuration = new axs.AuditConfiguration();
configuration.ignoreSelectors('lowContrastElements', '.pretty');
axs.Audit.run(configuration);
The AuditConfiguration.ignoreSelectors()
method takes a rule name, which you can find in the audit report, and a query selector string representing the parts of the page to be ignored for that audit rule. Multiple calls to ignoreSelectors()
can be made for each audit rule, if multiple selectors need to be ignored.
Restrict the scope of the entire audit to a subsection of the page
You may have a part of the page which varies while other parts of the page stay constant, like a content area vs. a toolbar. In this case, running the audit on the entire page may give you spurious results in the part of the page which doesn't vary, which may drown out regressions in the main part of the page.
You can set a scope
on the AuditConfiguration
object like this:
var configuration = new axs.AuditConfiguration();
configuration.scope = document.querySelector('main'); // or however you wish to choose your scope element
axs.Audit.run(configuration);
You may also specify a configuration payload while instantiating the axs.AuditConfiguration
,
which allows you to provide multiple configuration options at once.
var configuration = new axs.AuditConfiguration({
auditRulesToRun: ['badAriaRole'],
scope: document.querySelector('main'),
maxResults: 5
});
axs.Audit.run(configuration);
License
Copyright 2013 Google Inc. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Top Related Projects
Accessibility engine for automated Web UI testing
Pa11y is your automated accessibility testing pal
WAI-ARIA Authoring Practices Guide (APG)
Automated auditing, performance metrics, and best practices for the web.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot