axe Developer Hub Glossary
Terms useful for understanding axe Developer Hub
a11y
Number-based abbreviation (or numeronym) for the word "accessibility", with "11" (eleven) representing the number of characters between the starting "a" and ending "y" in accessibility. Pronounced as ally.
API Key
For authorization, you will generate an API key in Axe Account Settings. You can use the same API Key for multiple projects, although you must use an Axe Developer Hub API Key only for web projects and an Axe DevTools Mobile API Key only for mobile projects.
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 create as many projects as you need to view and manage accessibility in your websites and mobile apps.
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.
Build ID
The build ID is automatically generated as a UUID when not provided by the user, and it is used to link scans together as a single testing session. When running a test suite across multiple machines or environments, providing a build ID will link all of these runs together and be displayed as a single session in Developer Hub.
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.
e2e Testing
End-to-end, or e2e, testing refers to testing the entire web application's functionality by testing its real-world implementation. With Axe Developer Hub, you can test e2e scenarios for accessibility problems.
Experimental Rules
Experimental rules are still being developed and tested to address new technologies or increased understanding and awareness of accessibility issues. These rules shouldn't be relied on in production environments because they're still in development and are subject to false positives. Eventually, rules in this rule set could become part of accessibility standards. Experimental rules are disabled by default. See Experimental Rules for the rules that make up this rule set in the latest version of axe-core.
Git
Many Developer Hub projects have test suites that use a Git repository. Using Git allows you to associate accessibility defects with code on different branches and in specific commits, aiding in their resolution.
Gitless
Gitless refers to a Developer Hub project with a test suite that doesn't use a Git repository. While not required, 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 users with disabilities, with the highest legal liability. While minor and moderate issues are not as severe, they are still crucial for compliance and addressing the needs of those with disabilities.
The four levels used to categorize the impact of accessibility issues are:
-
Minor: Issues that affect users with disabilities 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.
Modified Test Suite
A modified test suite is a test suite you've changed according to the instructions provided by Axe Developer Hub when you created a new project. Modifying your test suite allows you to add accessibility testing to your existing test suite with minimal changes to the test suite itself.
Organizational Administrator
An organizational administrator (org admin) is a user with administrative privileges for their entire enterprise in Axe Account. Org admins can view all projects in their enterprise and manage project members and settings, regardless of whether they are a member of a given project. Org admin status takes precedence over project-level roles. Org admins must have an active Axe Developer Hub or Axe DevTools for Mobile license to create new projects or send results to Axe Developer Hub but can manage existing projects without a license.
Page State
The page state refers to the state of a web page's document object model (DOM) at a specific time. Viewing different page states is 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
When using Watcher, the package rescans web pages whenever 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). You create and name a new project in Developer Hub, which creates a Project ID to be used with your tests to identify the project and associate results data with the project.
Project Admin
A project admin is a project member with elevated permissions. Project admins can do everything a project member can, plus manage project settings, add or remove members, and change member roles. When using Axe Watcher, a project admin's API key is required to run tests in a pipeline.
Project ID
A Project ID is generated automatically when you add a new project, to associate your results data with that project. Both a Project ID and API key are required to send accessibility results to Developer Hub. It is best practice to map one project ID to one test suite/repository, to more accurately track the accessibility status of your project.
Project Member
A project member is a user who has been added to an Axe Developer Hub project. Project members can run tests and view results within the project. Members must have an active license to access the project.
SHA
When you create a commit with Git, it creates an ID to uniquely identify the commit. This 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 backward compatible with WCAG 2.1.