Glossary

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

Terminology used by axe DevTools for Web

Not for use with personal data

An abbreviation for accessibility: interpreted as the letter a followed by 11 characters then the letter y.

Agora

Agora is Deque's internal artifact repository. It is based on an Artifactory instance. Through Agora, users can download axe DevTools components, manage and distribute custom rule sets, and more.

ARIA

Accessible Rich Internet Applications (ARIA) is a technical specification published by the World Wide Web Consortium, or W3C, that defines ways to increase the accessibility of web pages, in particular, dynamic content and user interface components developed with Ajax, HTML, JavaScript, and related technologies.

Assistive Technology

Some disabled individuals may not be able to interact with software and websites on their own. These individuals require assistive technology to use the internet in an equitable way. One very common form of assistive technology is a screen reader. These devices read the text on the screen out loud for low vision or blind individuals. There are many different screen readers depending on the platform. Some examples are NVDA or JAWS on PC, VoiceOver on Mac, or TalkBack on Android.

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

For axe Watcher, 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

Checkpoint

A proven method for accessibility requirements testing created by Deque's team of a11y experts that increases the consistency and accuracy of testing results. Based on the WCAG Success Criteria, they provide a more explicit categorization and interpretation of those guidelines, wherein failures are typically separated by content type. The Deque Checkpoints help reviewers produce consistent and accurate test results during accessibility assessments. A checkpoint refers to the most relevant and applicable section of the master listing of the Deque Checkpoints (and their requirements) that are an important part of the Deque Way to digital equality.

Component Testing

With Cypress or Playwright and axe Watcher, you can test individual components (such as React components) in isolation. Contrast this with e2e Testing, which tests the entire web application in its real-world implementation. Axe Developer Hub can detect accessibility problems in end-to-end scenarios and can test components in isolation with Cypress. See e2e Testing.

Configuration Override

A configuration override allows you to customize settings for specific test runs through the (JavaScript/TypeScript) configurationOverrides property or (Java) ConfigurationOverrides Class in your test configuration. These overrides must comply with your organization's global configuration settings and can include changes to accessibility standards, best practices, experimental rules, and axe-core versions.

Custom Ruleset

A custom ruleset is built from a JSON file containing rule data (rules and checks) passed to axe DevTools components to add new rules, change the severity/impact of a rule, or remove a rule from 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.

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 and can test individual components in isolation with Cypress. See also Component Testing.

Event

To track API or CLI usage, the metrics library creates events and sends them to the usage service. Events contain information about usage such as number of accessibility rules violated during a web page scan and the date and time an accessibility scan was completed.

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.

Flush

The flush function writes your axe Watcher 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 Watcher package with a test suite that doesn't use 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.

Global Configuration

Global configuration is part of axe Configuration that allows you to set various options in one place to be shared between different Deque products. Your admin can allow certain settings to be changed by users.

Identity Token

An Identity Token is a security token issued by JFrog that allows you to access Deque's Agora artifact repository. Identity Tokens must be copied at the time of creation because this is the only opportunity to access them. They expire after a designated time interval, typically one year.

Impact

Every accessibility violation is assigned an impact level. Impact is a useful metric when prioritizing remediation efforts. By default, each violation type is assigned an impact level by Deque accessibility experts. These values are generalized to most situations, so users may use their judgment to change them as a part of their ruleset customization. Serious or critical impact levels corelate to disabled users encountering significant or insurmountable usage barriers. These carry the greatest degree of legal liability. Minor and moderate issues aren’t as serious, but still represent important issues for disabled users and require addressing for the page to be fully compliant. The following four levels are used to categorize the impact of detected accessibility issues:

Critical: This impact level means users with a disability will be blocked completely from accessing or interacting with a feature on the web page. Until a solution is implemented, the content will be totally inaccessible. This makes your organization highly vulnerable to lawsuits. Remediation of critical issues should be a top priority.
Serious: This impact level means users with a disability will face serious barriers when interacting with the site. These users will experience significant frustration when attempting to access related content. Until a solution is implemented, some content will difficult or impossible to access, making your organization vulnerable to legal action. Remediation should be a high priority.
Moderate: This impact level means some barriers exist for users with a disability, but they would not prevent them from accessing basic flows or content. Issues with impact at this level may make your organization vulnerable to legal action. They require resolution before a page is fully compliant, and should be remediated.
Minor: An issue that yields less impact for disabled users than a moderate issue. The issue may constitute a lower priority than moderate, serious, and critical issues, but still requires resolution for a page to be fully compliant.

Intelligent Guided Testing (IGT)

Intelligent Guided Testing (IGT) is an interactive accessibility testing component of the axe DevTools web browser extensions designed to find accessibility errors that cannot be detected in automated testing. IGT asks the user simple questions about the webpage under test and uses this feedback to locate more accessibility errors than would otherwise be possible with automated testing. To learn more about Intelligent Guided Tests, visit the Intelligent Guided Tests documentation.

Issue

A violation of accessibility guidelines (as defined by standards such as WCAG 1.0, WCAG 2.0, Section 508 and WAI-ARIA) identified in webpage or web application code.

JSON Accessibility Results

When you test a website for accessibility issues using the axe DevTools APIs or CLI, your results are saved as a JSON file which is referred to in the documentation as a JSON accessibility results file. You can upload this file to axe Reports (which allows you to monitor your website's accessibility over time through the axe Reports website). You can also filter and convert the JSON accessibility results file locally to .csv, .xml, or .html using the CLI. See Reporting with the CLI for more information. Alternatively, the APIs also allow you to convert JSON accessibility results files to reports during a test run (see Reporting below for more information).

Manual Mode

By default, axe Developer Hub analyzes each of your web pages automatically and re-analyzes pages whenever it detects a new page state. You can disable this automatic behavior by

(JavaScript/TypeScript) Setting the autoAnalyze property on the axe configuration object to false.
(Java) Calling the setAutoAnalyze() method with false.

You can also override the automatic analysis behavior by

(JavaScript/TypeScript) Calling the stop() method.
(Java) Calling the AxeWatcherController.stop() method.

In either case, this puts Watcher in manual mode. In manual mode, pages are only analyzed when you call the analyze() method.

Metrics Library

An internal library used by Deque's APIs and CLI to report usage information to the usage service.

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.

Needs Review

An issue requires inspection by a human to determine if the issue is an actual violation of accessibility standards.

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 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 project ID. When you create and name a new project in axe Developer Hub, it generates a project ID that you use with your tests to identify the project.

Reporting

Reporting refers to uploading a JSON accessibility results file to axe Reports or converting it locally to a report (a .csv, .xml, or .html file) for use in another application.

RGAA

RGAA, or Référentiel Général d'Amélioration de l'Accessibilité, is the French government's web accessibility standard. It is largely based on WCAG 2.1 and provides specific technical criteria for assessing the accessibility of web content. The current supported version is RGAA 4, identified by the ruleset ID rgaav4.

Rule

A rule corresponds to an accessibility guideline success criteria. They are defined by JSON object files and contain an id, description, and help metadata as well as one or more checks and optional parameters.

Section 508

An amendment to the United States Rehabilitation Act of 1973 that requires federal agencies to make their electronic and information technology accessible to people with disabilities. It comprises sixteen provisions based on access guidelines developed by the Web Content Accessibility Guidelines (WCAG) developed by the World Wide Web Consortium (W3C) but are not identical to either WCAG 1.0 or 2.0 standards.

SHA

When you create a Git commit, it generates an ID that uniquely identifies the commit. The unique ID is called a SHA (an acronym for the Secure Hash Algorithms, a group of cryptographic hash functions).

Usage Service

A REST web service that records usage metrics for axe DevTools for Web (APIs and the CLI). It is either the public-facing service provided by Deque or your own service. For more information, see The axe DevTools for Web Usage Service.

Violation

An issue identified by axe DevTools that violates one or more accessibility standards.

Watcher

The code component that you integrate into your test suite is called Watcher. Deque provides several editions of the package for the supported languages and test frameworks. You integrate the Watcher package into your website test suite to analyze web pages and report the results to axe Developer Hub, where you can view the results. The Watcher package also scans the current Git commit and branch and associates test runs with it.

WCAG

WCAG, or Web Content Accessibility Guidelines, were developed by the World Wide Web Consortium (W3C) and explain how to make Web content more accessible to people with disabilities. WCAG 1.0 was published in May 1999. WCAG 2.0 was published in December 2008. WCAG 2.0 applies broadly to more advanced technologies and is more precisely testable with automated testing and human evaluation. WCAG 2.1 was published in June 2018. These guidelines contain success criteria which define testable criteria for specific elements. WCAG 2.2, the most recent iteration of the guidelines, was published in 2023 and offers nine new success criteria over WCAG 2.1.

Wrapping

Wrapping refers to modifying a browser automation platform (such as Cypress) to call accessibility testing code (in the 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.