- What is this?
- What is the status of this project?
- Can't this be automated?
- What Assistive Technologies are in scope?
- Who runs this?
- What are the levels of support?
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 2.0, 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 can not 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:
- Are closed sourced (no contributions)
- Do not cover all of the common AT
- Do not disclose exactly how tests are performed
- Only tests a specific technology (or a subset of that technology)
- Only tests the accessibility API layer, not the end result of the AT
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 as this but with more community support and detailed assertions and methodology. The ARIA-AT group is still in the planning phases 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 different ways that Assistive Technology (AT) interacts with a browser and your code.
- 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.
- The AT will directly interface with the browser and read the DOM.
- 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:
- Screen reader software
- Voice Control software
Testing every possible combination of AT and Browser is simply unrealistic. We organize both AT and Browsers into two categories:
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 are used to determine what should be considered 'core':
For each category of AT that is within the scope:
- AT that is built into the operating system if it is used by at least 10% of respondents + the native browser on that operating system. This currently includes:
- VoiceOver + Safari for Mac
- VoiceOver + Safari for iOS
- Windows Narrator + Edge
- Talkback + Google Chrome
- Free or Open source AT (eg. NVDA) that this is widely adopted + the browser with the highest usage for the AT. This currently includes:
- NVDA + Firefox
- AT that requires a paid license and is widely adopted + the browser with the highest reported usage for the AT. This currently includes:
- JAWS + IE and Firefox (both IE and Firefox should be tested as users transition away from IE)
- Dragon Naturally Speaking + Google Chrome (voice control software)
- AT that has published documentation of supported combinations
- JAWS + Chrome and Firefox
- NVDA + Firefox
The phrase 'widely supported' for core AT means that greater than or equal to 20% of respondents use it as their primary AT.
Extended combinations include rarer AT/Browser combinations that are used by at least 10% of respondents + the major browsers available on the operating system.
Major browsers are defined as Google Chrome, Edge, Firefox, Internet Explorer, and Safari.
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 were developed by Michael Fairchild with encouragement from the web development community at the University of Nebraska - Lincoln. The data and software are opened 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):
- u = unknown
- n = no support
- y = full support
- p = partial support (unusual)
- na = not applicable
For a test or feature:
- Full support (all core support points are fully supported across all tests)
- Some support (some core support points are fully supported across all tests)
- No support (no core support points are fully supported across all tests)
- Unknown (all core support points are unknown)