Glossary

Link to Glossary copied to clipboard

This page describes the key terminology used in the axe Auditor user interface that users of the system must understand. It includes definitions and explanations of terms, abbreviations and acronyms that could potentially be unfamiliar to you.

Accessibility Compliance Chart of Dashboard : The Compliance Chart indicates the overall score of accessibility compliance over the set of pages and/or components defined in the scope of the test case. The percentages are calculated based on number of total checkpoints passed or failed across the defined scope. The checkpoint will be counted to failed list if it is failed at least once on any of the page or component of the defined scope.

Assistive Technology : Test Runs allow for the specification of the software and devices used by disabled individuals to interact with software and websites. Some tests will require use of a screen reader, such as NVDA or JAWS on PC, or VoiceOver on Mac. Read more information at https://en.wikipedia.org/wiki/Assistive_technology

Attest : A part of Deque's Enterprise Accessibility Conformance suite of products, axe DevTools is the premium accessibility rules engine that executes comprehensive automated testing inside axe Auditor. As a standalone product it is a lightweight, fast and portable JavaScript library that runs on your local development server in the same browser as your functional or unit tests, seamlessly integrating with the testing framework or browser of choice. In any mature, agile development cycle, developers and testers are empowered to catch accessibility issues early, and rapidly resolve them using the built-in references and solution patterns from the deep, context-sensitive help that taps into the Deque University accessibility knowledge base.

Checkpoint : A proven method for accessibility requirements testing created by Deque's team of accessibility 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 66 Deque Checkpoints (and their requirements) that are an important part of the Deque Way to digital equality.

Completion Status : The three states of completion related to Test Runs in axe Auditor are "not started" (test case assigned to user, but not yet started), "in-progress" (either automated or manual testing has been started, but all checkpoints have not yet been assigned a result for all pages that comprise the test run), and "complete" (meaning all checkpoints for all pages have been marked with a completion result of either Pass, Fail, or N/A for both automated and manual testing).

Compliance Data & Impact : A grouping of 6 related fields of information that give you a quick snapshot of the type of compliance information and accessibility impact associated with this rule. A listing of the applicable standards to the rule, which may include W3C WCAG 2.0 levels A and AA, as well as US Section 508 guidelines and/or Deque Way Best Practices. Customization of rules and associated automated checks that run makes possible organization-specific standards testing. Severity classifications (Blocker, Critical, Serious, Moderate, or Minor) refer to compliance violation (rule failure) levels that describe how serious an impact the issue(s) have on the accessibility of a site or page.

Component : A component represents global and re-usable sections of the website. User can also define components to be part or section of a particular page. Axe Auditor expects proper selectors to be defined to identify components of a page.

Dashboard : Dashboard of a completed Test Run comprises of three charts indicating the level of accessibility conformance, impact of issues on people with different disabilities and top issues with number of times repeated. All of these charts data is based on Deque-Way methodology used in axe Auditor to test against a given standard. For example, as per Deque-Way, we evaluate 66 checkpoints against each page or component if the selected standard is WCAG 2.0 Level A & AA.

Digital Asset Type

: This field is used to define the type of asset or property being tested. The benefit of this is that only the checkpoints relevant to the asset selected (the testing, remediation and the best practice methodologies) will display show up for the manual testing. The non-applicable checkpoints will be hidden, so there is only relevant checkpoints to review. Options to choose from are:

  • Desktop Web
  • Mobile Web
  • Native Mobile Android
  • Native Mobile iOS
  • Kiosk
  • MS Excel Documents
  • MS PowerPoint Documents
  • MS Word Documents
  • Windows Desktop Software

Disabilities Affected : One or more of the following is displayed to indicate which disabilities are impacted by the rule not being met:

  • Attention Deficit
  • Cognitive
  • Color-blindness
  • Deafness
  • Dyslexia
  • Hard-of-hearing
  • Low Vision
  • Seizure
  • Sighted Keyboard Users
  • Speech

Environment : Test Runs allow for the specification of the type of server being tested on. For example, a production server would be used for a live site.

Folder : A folder is simply a container for test cases used to organize them. It is used to categorically group related test cases. Consult your Quality Assurance Manager prior to creating a new test case for the most appropriate folder to associate it with. When a new test case is created and a folder is not selected, it will automatically be created within the Unorganized folder by default. Existing test cases can be moved to different folders at any time.

Impact : User impact is a useful metric to use when prioritizing remediation efforts. Default levels are associated with each Deque Checkpoint according to what Deque accessibility experts have determined is generally true for a particular type of accessibility issue, but assessors may use their judgment to change them. Blocker, Critical and Serious impacts occur when an user encounters significant barriers or is blocked from content on the site with a greater vulnerability to legal action. Minor and moderate issues aren't as serious, but still must be dealt with for the page to be considered fully compliant. Checkpoint tests cover accessibility guidelines which can have the following five levels used to categorize the accessibility impact of issues within the axe Auditor application.

  • Blocker: Results in catastrophic roadblocks for people with disabilities. These issues will definitely prevent them from accessing fundamental features or content, with no possible workarounds. This type of issue puts your organization at high risk. Prioritize fixing immediately, and deploy as hotfixes as soon as possible. Should be extremely rare. An example of a blocker issue is a SC 2.3.1 --- Three Flashes or Below Threshold which can cause seizures
  • Critical: This issue results in blocked content for individuals with disabilities. Until a solution is implemented content will be completely inaccessible, making your organization highly vulnerable to legal action. Remediation should be a top priority.
  • Serious: This issue results in serious barriers for people with disabilities, and will partially prevent them from accessing fundamental features or content. People relying on assistive technologies will experience significant frustration as a result. Issues falling under this category are major problems, and remediation should be a priority. Should be very common.
  • Moderate: This issue results in some barriers for individuals with disabilities but would not prevent them from accessing fundamental elements or content. This might make your organization vulnerable to legal action. This violation must be resolved before a page can be considered fully compliant.
  • Minor: This is considered an issue that yields less impact for users than a moderate issue. For a page to be considered fully compliant this issue must be resolved but can be dealt with last.

Issue : In the context of axe Auditor, each consists of a required summary, impact level, as well as an association with a Deque Way Checkpoint. Additional information that can be stored within an issue record include an issue type, description type, description, review flags, source code, screenshots and remediation recommendation. Each issue pertains to a particular testing page.

Issue Type : Refers to the type of failure or best practice. The following 5 issue types are used to categorize issues within the axe Auditor application:

  • Accessibility: The issue impacts the ability for a disabled user to access content or functionality of the site. Fails the checkpoint test.
  • Best Practice: The issue impacts the ability for a disabled user to access content or functionality of the site, but does not fail the checkpoint test.
  • User Agent: The issue is a result of the user agent interaction with the page, not necessarily the page content itself.
  • Functionality: The issue is a result of a problem with the functionality of the page and should be considered a functional defect.
  • Usability: The issue impacts the ability for all users to access content or functionality of the site.

Method : Method of an issue indicates how the subject matter expert found an issue, through either automation or manual. We use Deque tools for automation test results and use Deque Way for manual test results.

Other Related Resources : External links to pages on non-Deque sites known as reputable sources of quality information about the specific rule.

Page : A page in axe Auditor refers to a "page under test" or a "testing page." On a Test Case creation screen, the Add Page dialog box functionality is used to add pages to be tested. A Page represents the individual page, component, or content within a test case that you want to test for accessibility. Although you are specifying a URL and Name for the page, the Scope to be tested may be the whole page, or an area of the page (which can be a module, screen, widget, section, or element).

Platform : The operating system(s) and browser(s) on which the site is to be tested. For example, "Windows and Firefox" or "Android and Chrome." Automated testing will be run through a connected browser on a given platform.

Related Deque University Course Pages : A link to the topic is followed by a parenthetical link to the course in which the topic is contained. This takes you directly to the Deque University page where a high level of detail is provided about the nature of the rule and why it is important.

Release : Test Runs allow for the specification of the version number of the product being tested. For example, 1.0 would be the first release cycle of the product.

Related Deque University Course Pages : A link to the topic is followed by a parenthetical link to the course in which the topic is contained. This takes you directly to the Deque University page where a high level of detail is provided about the nature of the rule and why it is important.

Relevant Technologies : One or more relevant technologies is displayed to demonstrate the types of technologies in which the rules can be run.

Remediation Recommendation : Remediation recommendation is our Deque experts suggestion on how to fix a particular issue. This will be of a great help for developers. Sometimes, it also indicates how this problem affects a person with disability and the type of disability that suffers from this failure.

Section 508 Guidelines : Specific subsections of the related Section 508 guidelines are referenced when applicable.

Selector : Selector is way to identify an element using some techniques (example: xpath, id, css class) on a webpage DOM that helps to identify a particular component.

Severity : Blocker, Critical, Serious, Moderate, and Minor are the five categories of issue (rule failure) severity, as they relate to the various applicable guidelines and best practices.

Scope : Scope of a test case is a set of Page(s) and Component(s) URLs that are to be assessed for Accessibility Compliance against the defined standard. Each page or component is considered as a test unit by the axe Auditor application.

Source Code : Source code is the rendered DOM code of a target element of an issue. It helps developers to identify the element in the problem very easily.

Standard : The Standard field allows you to select either WCAG 2.0 Level A, WCAG 2.0 Level AA, WCAG 2.1 Level A, WCAG 2.1 Level AA, WCAG 2.0 Smoke test, Section 508 or Air Carrier Access Act (ACAA) when creating a new Test Case or when editing an existing Test Case. This setting refines the automated rules and manual checkpoint tests that are to be tested against in the Test Run to only those that are applicable to the selected standard.

Status : The three states of Test Run status in axe Auditor are "not started" (test case assigned to user, but not yet started), "in-progress" (either automated or manual testing has been started, but all checkpoints have not yet been assigned a result for all pages that comprise the test run), and "complete" (meaning all checkpoints for all pages have been marked with a completion result of either Pass, Fail, or N/A in manual testing).

Test Case : Test cases represent the testing scenario, steps, and product information required for a specific evaluation. They are made up of at least one page or component to be tested, and are named. Additional information includes a description of the test case, the applicable standard, and product information. The pages to be tested contained within a test case each include a page name, URL and scope --- which can either be the whole page or a specific page area (module, screen, widget, section or element) --- target elements (forms, video, audio, CAPTCHA, Flashing content), and related instructions such as those to be used for navigating to the page.

Test Reliability : A test against a rule includes multiple checks that, after running, produce a collective result. The reliability of the test is dependent upon results that can be definitively identified by automated means. Three categories of checks include "none must pass," "one must pass," and "all must pass" scenarios for each test. Automated tests are either considered Reliable, Somewhat reliable, or Unreliable --- in which case manual evaluation is required.

Test Run : A test run is an instance of a test case that has been assigned to a user to perform assessment against a specific combination of OS platform, Browser version and Assistive Technology. We do create number of test runs if we need to assess the given test case against number of combinations of OS, Browser and AT. Each test run can be assigned to a different user.

Test Unit : Test unit can be a page or component of a test case. Number of test units of a test case is equivalent to the sum of number of pages and components of a test case.

Testing Methodology : Deque Way is our methodology which is defined by Deque's team of accessibility experts to understand and interpret the WCAG in an accurate and easier way. This will make any upcoming client's accessibility teams more efficient if adopted.

Top Issues Chart of Dashboard : Top issues chart indicates the top checkpoints that are failed number of times across the scope of pages and/or components defined. The list is presented in descending order so user will see the top checkpoint with highest number of failures first. This chart will display maximum of top 10 checkpoints with most number of issues.

Topics : Too numerous to list here, all applicable Topic: Subtopic names are displayed to represent the broad category the rule falls under. These associations serve to group related types of rules/issues together.

User Impact Chart of Dashboard : User impact chart indicates how these identified accessibility issues will impact the people with different disabilities. You can find the definitions of severity by clicking the info icon link under the chart. Refer "impact" section of this glossary to understand how different issues with different impact level would impact the person with disability to use the functionality of the page.

WCAG Success Criteria : Success Criteria (SC) are written as testable statements that are not technology-specific. Subsections of the related WCAG guidelines are listed. The Deque Way Checkpoint issue categories are based on these groupings of related accessibility guidelines.

Key Concepts and Terms

Is this page helpful?

Help us improve this page

Still need help?