axe Developer Hub Glossary
Terms useful for understanding axe Developer Hub
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. Pronounced ally.
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.
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 integrate the @axe-core/watcher package in your website test suite to analyze web pages and report the results to axe Developer Hub where you can view the results. The @axe-core/watcher package also scans the current Git commit and branch and associates test runs with the current 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. Platforms include Cypress, Playwright, Puppeteer, WebdriverIO, and WebDriverJS. For more information, see
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:
-
Minor: Issues that affect disabled users less than moderate issues but still require resolution for full compliance
-
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.
-
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.
-
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.
Page State
The page state of a webpage refers to the 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
- 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 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.
SHA
When you create a commit with Git, it creates an ID to uniquely identify the commit. The unique ID is called a SHA (named after the Secure Hash Algorithms, a group of cryptographic hash functions).
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 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.
WCAG 2.2, the most recent iteration of these guidelines, was published in 2023 and offers nine new success criteria over WCAG 2.1. It supplies improved guidance for addressing the needs of users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. It is backwards compatible with WCAG 2.1.
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.