Important: This website does not attempt to establish a standard for how assistive technologies must behave. Read the FAQ for more information. Additionally, this is a work in progress. Please submit feedback or suggestions.

FAQ

What is this?

This is a community-driven website that aims to help inform developers about what code features (roles, states, properties, elements, etc.) are supported by assistive technologies, and what that support looks like.

Our goal is not to tell you what you can or cannot use, but to help you make informed decisions. For example, you may be able to use unsupported features in a way that does not negatively effect AT interaction.

We also hope to help developers learn how to test with assistive technologies. To accomplish this, we will provide introductory materials on how to use different assistive technologies and provide detailed instructions about how to perform tests. We also hope to run workshops at developer conferences.

There are some other projects that are similar to this, however, most of them:

Is this a standard for how assistive technologies need to behave?

Important: This website does not attempt to establish a standard for how assistive technologies (such as screen readers) must behave or dictate how assistive technologies must provide support (no such standard exists). It should not be used as the only source for determining if something is supported. Instead, it is meant to help visitors get a head start in understanding behaviors, general expectations, and support.

How should I interpret results? How do I know if it's okay to use a feature?

Interpreting results can be fairly complex, so here are some general suggestions:

How do I get bugs fixed?

It's not always easy to tell who is responsible for fixing a bug. If you can find the root cause and, please report it to the appropriate assistive technology or browser. To do this:

  1. Find the root cause and who is responsible for fixing it (assistive technology or browser). If you can't tell, open an issue in this project for help.
  2. Find out if the bug has already been reported. Where to look:
    • Search for the feature in this project. We try to list links to known bugs for each feature. These can be found under the "Related issues, discussions, and bugs" heading on each feature page.
    • Look in relevant bug trackers and look at the relevant feature pages in this project.
  3. If you can't find an existing bug report, go ahead and report it.
  4. If you have a URL to the bug report, open an issue in this project and let us know about the bug report. We can link to it from the relevant feature page to make it easier for people to find the bug report in the future.

Report issues with assistive technologies:

Report issues with browsers:

What is the status of this project?

This project is active and contributions are welcome. That being said, I still consider the project to be a work-in-progress. Additionally, I am co-chairing the W3C ARIA-AT Community group which has a goal to create a similar project but with a slightly different approach and reduced scope. At some point in the future, the ARIA-AT project might nullify this project.

Can this be automated?

There are many ways that Assistive Technology (AT) interacts with a browser and your code.

  1. Accessibility APIs (most common). In this method, a browser will create an accessibility tree (a subset of the DOM) and expose it to a system Accessibility API. The AT will then consume that API. This mapping is being standardized for many technologies via the Accessibility API Mapping standards.
  2. The AT will directly interface with the browser and read the DOM.
  3. A mixture of 1 and 2.

It is possible to automatically test the Accessibility APIs and DOM, but the AT itself might have bugs or not fully implement certain features.

Unfortunately, it is not yet possible to fully drive AT in an automated way, so we are left with having to do manual tests.

Note: over the last few years, there have been many projects created to attempt to automate testing with various screen readers, each with varying degrees of success. However, this area is still not very mature and there is still not a standardized and robust way to perform this sort of testing at scale. For more information on this, please see ARIA-AT Automation.

Who runs this?

The community both runs and owns this project. The original idea and prototype was developed by Michael Fairchild with encouragement from the web development community at the University of Nebraska - Lincoln. The data and software are open sourced under the GPL 3.0 license.

What are expectations?

Expectations are conditions that must be met for the feature to be considered as "supported". Only "MUST" expectations need to be met for minimal "support". "SHOULD" and "MAY" expectations indicates support which goes above and beyond. Note that there is not an explicit standard which dictates these expectations, and as such, they are likely opinionated. As such, a feature might not meet all "MUST" expectations but still be usable (potentially frustratingly so). Additionally, the assistive technology may provide many commands to read, navigate, or otherwise interact with a feature. Only one command is usually required to pass for the expectation to be minimally supported.

What about expectations that are not directly testable by users?

There may be expectations for features that are not listed on this site. Some of these expectations are not directly testable by end-users. Wherever possible, we try to highlight which features have these expectations in our support listings. As a general rule of thumb, if the specification for the language being used requires the use of a feature, then use it (even if it appears to have poor support in our listings).

Take aria-controls as an example. As of writing, the attribute generally has poor support for user-facing expectations. However, it is still a required attribute for the combobox role and scrollbar role. The attribute creates a programmatic relationship between the controlling element and the controlled element. This programmatic relationship helps assistive technologies correctly support the role as a whole. Without the explicit relationship defined by aria-controls, the assistive technology might have to guess what the proper relationship is. Most of the time, it will guess correctly and end-users won't notice anything is wrong. But this guessing comes at the potential cost of reliability and performance.

What are the levels of support?

There are several levels of support.

For specific commands:

For expectations:

Important: Failing results such as "fail" or "none" just means that there is no known/documented support. There may still be support for this expectation, but it is undocumented. If this is the case, please report this issue.

There are also two grading methods:

What Assistive Technologies are in scope?

The Accessibility Supported conformance requirement in WCAG does not specify what technologies must be supported. Our core support list may not match the list of technologies that you choose to support for any given project.

Our goal is to test against a manageable list of common and widely available AT.

We list Assistive Technologies that must interact with code in order to be operable. This boils down to two main categories of AT:

  1. Screen reader software
  2. Voice control software

Testing every possible combination of AT and Browser is simply unrealistic. We organize both AT and Browsers into two categories:

  1. Core
  2. Extended

Core AT + Browser combinations

Core AT and Browsers are commonly used or widely available. We try to keep the list to a minimum in order to make testing easier. The following rules determine what should be considered 'core':

For each category of AT that is within the scope:

  1. AT that is built into the operating system + the native browser on that operating system.
  2. Free or Open source AT (eg. NVDA) that are widely adopted + browser combinations that are widely adopted for that AT.
  3. AT that requires a paid license that are widely adopted + browser combinations that are widely adopted for that AT.
  4. AT that is widely adopted and has published documentation of supported combinations.

The phrase 'widely adopted' for core AT means that greater than or equal to 10% of respondents use it as their primary AT.

Extended Combinations

Extended combinations include rarer AT/Browser combinations but is limited to major AT and major browsers.

Major AT is defined as AT that is either built into operating systems or survey data shows at least 10% usage. Major browsers are defined as Google Chrome, Edge, Firefox, Internet Explorer, and Safari.

Survey Sources

For now, we base our data on the results of the latest

Where does the name Accessibility Supported come from?

WCAG has an accessibility supported. It basically says that if a feature is relied upon to meet a given success criteria, that feature must be supported by AT. WCAG makes this very unclear by purposefully not defining exactly which AT need to be supported or at what level the support needs to be at. Instead, this decision needs to be made on a case by case basis and within the context of your project and who will be using it.