If you don't see an answer to your question here, check out Help and Release notes.
How do I run Accessibility Insights for Web on local files?
- Open your browser's Extensions page:
- In Chrome, go to chrome://extensions/
- In the new Microsoft Edge, go to edge://extensions/
- Find Accessibility Insights for Web and select Details.
- Turn on the Allow access to file URLS toggle.
How do I run Accessibility Insights for Web in Incognito mode?
- Open your browser's Extensions page:
- In Chrome, go to chrome://extensions/
- In the new Microsoft Edge, go to edge://extensions/
- Find Accessibility Insights for Web and select Details.
- Turn on the Allow in Incognito toggle.
Which browsers are compatible with Accessibility Insights for Web?
Accessibility Insights for Web is currently compatible with:
- Chrome
- Edge
What type of issues can be found with FastPass in Accessibility Insights for Web?
FastPass has two steps:
- Automated checks: this checks are powered by axe-core and can detect some common accessibility problems, such as missing or invalid properties. However, most accessibility problems can be identified only through manual testing and Automated checks only provide partial coverage to WCAG success criteria.
- Tab stops: an assisted manual test that helps you find some accessibility issues in keyboard navigation. In some cases, this test will also automatically detect potential keyboard access issues.
Can automated checks in Accessibility Insights for Web detect issues in content that's currently hidden?
Some automated checks run only on visible content; they ignore content marked with display: none
or visibility: hidden
. To fully test content that's hidden by default – such as combo box options, dialog boxes, and menu options – you'll need to reveal the content before running automated checks:
- Use your mouse or keyboard to reveal the hidden content.
- Run the automated checks using the keyboard shortcut. The default shortcut is
- Alt+Shift+1 in Windows
- Option+Shift+1 in macOS
How do I run automated checks on revealed content that disappears when focus moves away?
If revealed content – such as combo box options, dialog boxes, and menu options – disappears when focus moves away, you can run automated checks using the keyboard shortcut provided in Ad hoc tools:
- Use your mouse or keyboard to reveal the hidden content.
- Use the keyboard shortcut to run automated checks.
- The default shortcut in Windows is Alt+Shift+1.
- The default shortcut in macOS is Option+Shift+1.
- View the results:
- To view results in the target page, click an error icon (red rectangle with white exclamation point).
- To view results in a list:
- Open the Accessibility Insights for Web extension.
- In the Launch pad, select Ad hoc tools.
- Under Automated checks, select List view and filtering. Results will open in a new browser window.
Are automated checks compatible with shadow DOM?
Automated checks are based on axe-core, which supports shadow DOM in open mode but not in closed mode.
Because closed mode prevents JavaScript from accessing an element's internal DOM, automated checks can't detect issues on components within a closed shadow DOM. Closed mode can also lead to false failure reports. For example, if an interactive component outside a shadow DOM is labelled by an element inside a closed shadow DOM, automated checks will report a missing label.
Shadow DOM in closed mode is sometimes implemented as an encapsulation measure. If you find that closed shadow DOM is interfering with automated checks, you might consider another approach to encapsulation.
Can I aggregate test results from multiple pages?
Test results – automated or manual – can't be aggregated across multiple pages or page states.
Is there a way to include automated tests in engineering pipeline?
If your project uses an end-to-end browser automation test framework, you can refer to samples available at axe-pipelines-samples to integrate automated accessibility tests in Azure pipelines. The samples use the same scanning engine, axe-core, that is used in Accessibility Insights for Web and demonstrate how automated accessibility tests are implemented in our own project pipeline.
Why does Accessibility Insights for Web ask for additional permissions when it detects iframes?
The permissions the Accessibility Insights for Web extension requests have been modified. Previously, the extension had more powerful permissions that allowed it to scan all websites; to provide additional security and privacy options to its users, as well as streamline the review process for publishing updates to the extension, permissions are now only requested for the active page Accessibility Insights is invoked from.
Since the permissions are only for that active page, if you have cross-origin iframes (for example, you are scanning foo.com and inside foo.com you have an iframe that points to bar.com) Accessibility Insights for Web will not have permissions for the iframe's host and will not be able to scan it.
By providing these additional permissions, you are ensuring your whole page, including the iframe, is being scanned.
You can manage these permissions by visiting the extensions page for your browser and selecting "Details' for the Accessibility Insights for Web extension.
What is the JSON schema used in assessment?
The JSON schema, as well as a full example output, is available in the Accessibility Insights for Web release Assets.
Each requirement in assessment can have 3 states: pass, fail and incomplete:
- If at least one requirement failed, the S.C is marked as fail.
- If at least one requirement is incomplete and there are no failed requirements, the S.C is marked as incomplete.
- If all the requirements pass, the S.C is marked as pass.
Where does Accessibility Insights for Web store scan data?
In general, Accessibility Insights for Web only stores complete scan data locally in the browser and does not upload results to any sort of external host.
If you chose to allow usage telemetry when you started the extension for the first time, it will upload some anonymous usage data. This includes information about how many violations of each type were found, but it does not include any information which would identify the user running the scan or the site the scan was run on - in particular, it does not include the URL or title of the site being scanned, nor the Path, Snippet or properties listed in the results in FastPass or Assessment. Telemetry is only sent if you opted in, and you can disable telemetry at any time from the Settings panel.
Why is the target page in the command bar of the Accessibility Insights for Web page a link?
This link is associated to the page you are testing (aka the target page); you can use this link to quickly return to it.
Can I use Accessibility Insights for Web to test a browser extension?
Accessibility Insights for Web cannot test other browser extensions directly because web browsers do not allow extensions to run scripts on other extensions' pages.
However, it is possible to run the "Automated checks" part of a FastPass or Assessment against a browser extension using an automated test. We recommend using Playwright for this. Some resources to learn more about this include:
- Playwright's documentation on testing browser extensions
- Playwright's documentation on accessibility testing
- Example project in the axe-pipelines-sample GitHub repository demonstrating accessibility testing with Playwright
Do you have more information or examples about the rules used by Accessibility Insights for Web?
More information about the specific rules can be found at Info and Examples for Accessibility Insights for Web
Can I run Accessibility Insights for Web automatically in a Continuous Integration environment?
Most of the tests in Accessibility Insights for Web require some human analysis, so it isn't possible to completely automate a FastPass or an Assessment.
However, it is possible to run the "Automated checks" part of a FastPass or Assessment in an automated test. You can find working examples of this in the axe-pipelines-samples GitHub repository.