Notice: This is a work in progress. Please submit feedback or suggestions.


What is this?

This is a community-driven website that aims to help inform developers about what is accessibility supported. In order to conform to WCAG, you must write code in ways that are supported by assistive technologies (such as screen readers).

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 affect 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:

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 that has a goal to create a similar project but with a slightly different approach and reduced scope. The ARIA-AT group is still in the planning phase, and I don't expect it to be mature enough to fully overtake this project any time soon. At some point in the future, the ARIA-AT project might nullify this project.

Can't 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.

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

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 the levels of support?

There are several levels of support.

For a given support point (specific to a test):

For a test or feature:

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 required to pass for the expectation to be minimally supported in some situations.