Glossary

a11y

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.

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.

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.

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.

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).

Metrics Library

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

Needs Review

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

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.

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.

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.

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.