axe Developer Hub Glossary

a11y

Number-based abbreviation (or numeronym) for accessibility with 11 (eleven) representing the number of characters between the starting a and ending y in accessibility.

API Key

An API key is created by axe Developer Hub whenever you create a new project. The key connects test runs and their results with a given project. It needs to be set in the test suite to allow its results to be associated with a specific project.

Automatic Mode

Automatic mode is the default mode for testing websites for accessibility errors. It analyzes web pages for accessibility errors automatically, unlike manual mode, which requires you to call the analyze function when you want to check a page. Typically, automatic mode is preferred because the @axe-core/watcher package detects changes to the page state and starts a new analysis when changes are detected.

axe Developer Hub

axe Developer Hub allows you to create new test projects and shows you the results of your accessibility test runs. You can filter the results by date, session ID, and severity. You can monitor your accessibility results and group them by session ID. You can create as many projects as you need to monitor different websites.

The @axe-core/watcher Package

You include the @axe-core/watcher package in your website test suite to analyze web pages and report the results back to axe Developer Hub where the results can be viewed. The @axe-core/watcher package also monitors Git commits and branches and associates test runs with a given commit.

Best Practices

Deque best practices are time-tested techniques that deliver desired accessibility results when specific formal methods are lacking or insufficient. While they are not officially included in any established accessibility rulesets, following Deque's best practices can enhance the accessibility and overall quality of the tested webpage. It should be noted that non-compliance with Deque's best practice guidelines does not automatically indicate a failure. Moreover, expert judgment is required to consider the appropriateness in the context of the application, site, or page goals. Sometimes the best practice accessibility technique isn't applicable or practical for resolving a specific issue. See Best Practices for the rules that make up the best practices rule set.

Browser Automation Platform

A browser automation platform is a framework you use to automate your website testing.

Duplicate

A duplicate is the same accessibility issue seen on the same document object model (DOM) node in multiple page states. If you fix an issue with duplicates, all of its duplicates will disappear because they're all the same issue.

Flush

The flush function writes your test results to the Deque server and is required to make sure the results are recorded by axe Developer Hub. You need to call the flush function in your test suite.

Gitless

Gitless refers to using the @axe-core/watcher package without a Git repository. You're not required to use a Git repository, but a Git repository allows you to associate accessibility defects with specific code changes, aiding in their resolution.

Impact

An impact level is assigned to every accessibility violation, categorized into four levels from least to most impactful: minor, moderate, serious, and critical. This metric helps prioritize remediation efforts, and Deque accessibility experts assign an impact level to each violation type by default.

Defects with serious or critical impact levels present significant or insurmountable barriers for disabled users, with the highest legal liability. While minor and moderate issues are not as severe, they are still crucial for compliance and addressing disabled users' needs.

The four levels used to categorize the impact of accessibility issues are:

1. Minor: Issues that affect disabled users less than moderate issues but still require resolution for full compliance

2. Moderate: Some barriers exist for users with disabilities but would not prevent them from accessing basic content or flows. These issues may make your organization vulnerable to legal action and should be remediated before achieving full compliance.

3. Serious: Users with disabilities will face significant barriers when interacting with the site, causing frustration and difficulty accessing related content. Remediation should be a high priority to avoid legal action.

4. Critical: Users with disabilities are completely blocked from accessing or interacting with a feature on the web page, making the content inaccessible and leaving your organization highly vulnerable to lawsuits. Remediation of critical issues should be a top priority.

Manual Mode

You can use the @axe-core/watcher package in manual mode if you want to analyze your web pages only after setting the web page in a specific state rather than letting the @axe-core/watcher package decide when to analyze the page.

Page State

The page state of a webpage refers to the current state of its document object model (DOM) at a specific time. Page states are helpful for complex websites with login screens or dynamic UI like single-page applications (SPAs). Examples of DOM state include the visibility of elements, the contents of elements, and the checked state of radio buttons and checkboxes. The @axe-core/watcher package rescans web pages when it detects changes to the DOM and saves a new page state each time.

Project

A project in axe Developer Hub holds accessibility results, test run information, and Git data (branches and commits). The association between this information and the project is through the project's API key. You create and name a new project in the axe Developer Hub, which creates an API key to be used with your tests to identify the project.

Session ID

The session ID is generated automatically as a UUID and identifies a user's login on a particular machine. Changing the session ID isn't typically required by most users. If you need to distinguish between different test runs, however, you can use different session IDs. You should use a globally unique ID like a UUID to prevent possible session ID collisions in the same organization.

Tag

A tag groups rules together that belong to a specific accessibility guideline like WCAG. For more information about the rules and the tags that those rules belong to, see axe-core Rule Descriptions

WCAG

WCAG, or Web Content Accessibility Guidelines, are a set of guidelines developed by the World Wide Web Consortium (W3C) to help make web content more accessible to people with disabilities. These guidelines provide a framework for creating accessible websites and digital content that can be used by people with a wide range of disabilities.

The three conformance levels of WCAG are defined by a set of success criteria that describe specific elements of web content that must be met to achieve that level of conformance. Conformance level A is the minimum level of conformance, while conformance level AAA is the most stringent. Conformance level AA requires conformance with both level A and level AA success criteria. Conformance with all three levels of success criteria (A, AA, and AAA) is required for conformance with level AAA.

WCAG 1.0 was the first version of these guidelines and was published in 1999. WCAG 2.0 was published in 2008 and provided more comprehensive guidelines for making web content accessible to people with a wider range of disabilities.

WCAG 2.1, the most recent iteration of these guidelines, was published in 2018. It builds upon the previous versions and includes new success criteria to address accessibility issues that have emerged since the release of WCAG 2.0. WCAG 2.1 also provides more guidance on mobile accessibility, low vision accessibility, and cognitive and learning disabilities.

Wrapping

Wrapping refers to modifying a browser automation platform (such as Cypress) to call accessibility testing code (in the @axe-core/watcher package) whenever a browser automation platform function is called. Wrapping allows you to integrate accessibility testing into your existing test suites with minimal changes to your code.