Convert Figma logo to code with AI

dequelabs logoaxe-core

Accessibility engine for automated Web UI testing

5,940
774
5,940
368

Top Related Projects

Automated auditing, performance metrics, and best practices for the web.

4,103

Pa11y is your automated accessibility testing pal

1,151

Web Content Accessibility Guidelines

1,530

JavaScript library to help modern web applications with accessibility concerns

Quick Overview

Axe-core is an accessibility testing engine for websites and web applications. It provides a fast and comprehensive way to detect and report accessibility issues, helping developers ensure their products are usable by people with disabilities.

Pros

  • Comprehensive: Covers a wide range of accessibility rules and best practices
  • Flexible: Can be integrated into various testing frameworks and CI/CD pipelines
  • Actively maintained: Regular updates and improvements
  • Well-documented: Extensive documentation and community support

Cons

  • Learning curve: May require some time to understand and implement effectively
  • False positives: Occasionally reports issues that may not be actual accessibility problems
  • Limited to web technologies: Not suitable for native mobile or desktop applications

Code Examples

  1. Basic usage with JavaScript:
axe.run().then(results => {
  console.log(results.violations);
});

This code runs an accessibility scan on the current page and logs any violations found.

  1. Running a scan with custom options:
axe.run({
  runOnly: {
    type: 'tag',
    values: ['wcag2a', 'wcag2aa']
  },
  exclude: [['#banner']]
}).then(results => {
  console.log(results.violations);
});

This example runs a scan with specific WCAG levels and excludes the element with ID 'banner'.

  1. Using axe-core with React:
import React, { useEffect } from 'react';
import axe from 'axe-core';

function AccessibilityChecker({ children }) {
  useEffect(() => {
    axe.run().then(results => {
      console.log(results.violations);
    });
  }, []);

  return <>{children}</>;
}

This React component wraps other components and runs an accessibility check when mounted.

Getting Started

To use axe-core in your project:

  1. Install the package:

    npm install axe-core
    
  2. Import and use in your JavaScript:

    import axe from 'axe-core';
    
    axe.run().then(results => {
      if (results.violations.length) {
        console.log('Accessibility issues found:', results.violations);
      } else {
        console.log('No accessibility issues detected');
      }
    });
    

This will run a basic accessibility scan on your web page and log any issues found.

Competitor Comparisons

Automated auditing, performance metrics, and best practices for the web.

Pros of Lighthouse

  • Comprehensive performance auditing, including accessibility, SEO, and best practices
  • Integrated with Chrome DevTools for easy access and usage
  • Provides detailed reports with actionable insights and recommendations

Cons of Lighthouse

  • Larger footprint and potentially slower execution compared to axe-core
  • May require more setup and configuration for custom integrations
  • Less focused on accessibility-specific issues compared to axe-core

Code Comparison

Axe-core (running an accessibility check):

axe.run().then(results => {
  console.log(results.violations);
});

Lighthouse (running an audit):

const lighthouse = require('lighthouse');
const options = {onlyCategories: ['accessibility']};
lighthouse('https://example.com', options).then(results => {
  console.log(results.lhr.categories.accessibility.score);
});

Both tools offer accessibility testing, but Lighthouse provides a broader range of audits and is more tightly integrated with Chrome. Axe-core focuses specifically on accessibility and offers a lighter-weight solution for developers who primarily need accessibility testing. The code examples demonstrate that axe-core has a simpler API for running accessibility checks, while Lighthouse requires more setup but offers more comprehensive auditing capabilities.

4,103

Pa11y is your automated accessibility testing pal

Pros of pa11y

  • Command-line interface for easy integration into CI/CD pipelines
  • Supports custom rulesets and configurations
  • Provides a wide range of output formats (JSON, CSV, HTML)

Cons of pa11y

  • Limited browser support compared to axe-core
  • Slower performance for large-scale testing
  • Less frequent updates and maintenance

Code Comparison

pa11y:

pa11y('https://example.com', {
  standard: 'WCAG2AA',
  ignore: ['notice', 'warning']
}).then((results) => {
  // Handle results
});

axe-core:

axe.run(document, {
  runOnly: {
    type: 'tag',
    values: ['wcag2aa']
  }
}).then((results) => {
  // Handle results
});

Both libraries offer accessibility testing capabilities, but they differ in their approach and implementation. pa11y provides a command-line interface and supports various output formats, making it suitable for integration into automated workflows. However, axe-core offers broader browser support and more frequent updates, making it a more robust choice for comprehensive accessibility testing across different platforms.

The code examples demonstrate the basic usage of each library. pa11y focuses on testing URLs, while axe-core is designed to run directly on the document object. Both allow for customization of rules and standards to be tested against.

1,151

Web Content Accessibility Guidelines

Pros of WCAG

  • Official W3C standard, providing authoritative guidelines for web accessibility
  • Comprehensive documentation covering a wide range of accessibility issues
  • Regularly updated to address evolving web technologies and user needs

Cons of WCAG

  • Not a directly implementable tool, requiring interpretation and manual implementation
  • Can be complex and overwhelming for developers new to accessibility
  • Lacks automated testing capabilities out of the box

Code Comparison

While WCAG doesn't provide direct code implementations, axe-core offers a JavaScript library for automated accessibility testing. Here's a basic example of using axe-core:

axe.run().then(results => {
  console.log(results.violations);
});

WCAG, being a set of guidelines, doesn't have equivalent code. Instead, it provides success criteria that developers must implement manually, such as:

<img src="example.jpg" alt="Description of the image">

This example follows WCAG guideline 1.1.1: Non-text Content, providing alternative text for images.

1,530

JavaScript library to help modern web applications with accessibility concerns

Pros of ally.js

  • Focuses on providing a comprehensive set of tools for creating accessible web applications
  • Offers a more modular approach, allowing developers to use only the parts they need
  • Provides utilities for managing focus and keyboard interactions

Cons of ally.js

  • Less widely adopted compared to axe-core
  • May require more manual implementation and configuration
  • Documentation is less extensive than axe-core's

Code Comparison

axe-core:

axe.run().then(results => {
  console.log(results.violations);
});

ally.js:

import ally from 'ally.js';

ally.maintain.tabFocus();
ally.when.visibleArea({
  context: '#my-element',
  callback: function(element) {
    // Element is in view
  }
});

Summary

While axe-core is primarily focused on automated accessibility testing and reporting, ally.js provides a set of tools for implementing accessibility features in web applications. axe-core is more widely adopted and offers comprehensive testing, while ally.js gives developers more granular control over accessibility implementations. The choice between the two depends on whether the primary need is for testing and auditing (axe-core) or for implementing specific accessibility features (ally.js).

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

axe-core

License Version NPM downloads Commits GitHub contributors Join our Slack chat Package Quality

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.

The Accessibility Rules

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.

Getting started

First download the package:

npm install axe-core --save-dev

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);
  });

Philosophy

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.

About axe - our Manifesto

  • Axe is open source.
  • It returns zero false positives (bugs notwithstanding).
  • It's designed to work on all modern browsers and with whatever tools, frameworks, libraries and environments you use today.
  • It's actively supported by Deque Systems, a major accessibility vendor.
  • It integrates with your existing functional/acceptance automated tests.
  • It automatically determines which rules to run based on the evaluation context.
  • Axe supports in-memory fixtures, static fixtures, integration tests, and iframes of infinite depth.
  • Axe is highly configurable.

Supported Browsers

The axe-core API fully supports the following browsers:

  • Microsoft Edge v40 and above
  • Google Chrome v42 and above
  • Mozilla Firefox v38 and above
  • Apple Safari v7 and above
  • Internet Explorer v11 (DEPRECATED)

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.

Contents of the API Package

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 file

Localization

Axe 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:

axe.configure({
  locale: {
    lang: 'de',
    rules: {
      accesskeys: {
        help: 'Der Wert des accesskey-Attributes muss einzigartig sein.'
      }
      // ...
    },
    checks: {
      abstractrole: {
        fail: 'Abstrakte ARIA-Rollen dürfen nicht direkt verwendet werden.'
      },
      'aria-errormessage': {
        // Note: doT (https://github.com/olado/dot) templates are supported here.
        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.).'
      }
      // ...
    }
  }
});

Supported Locales

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.

  • Basque
  • Danish
  • Dutch
  • French
  • German
  • Hebrew
  • Japanese
  • Korean
  • Norwegian (BokmÃ¥l)
  • Polish
  • Portuguese (Brazilian)
  • Spanish
  • Greek
  • Italian
  • Simplified Chinese
  • Traditional Chinese

Updates & Security

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.

  • See release and support for details on the frequency of releases, long-term support and recommendations on upgrading axe-core.
  • See backward compatibility for details on the types of changes different releases may introduce.

Deque Trademarks Policy

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.

Supported ARIA Roles and Attributes.

Refer axe-core ARIA support for a complete list of ARIA supported roles and attributes by axe.

Contributing

Read the Proposing Axe-core Rules guide

Read the documentation on the architecture

Read the documentation on contributing

Projects using axe-core

List of projects using axe-core

Acknowledgements

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.

Licenses

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)

NPM DownloadsLast 30 Days