Watch a short intro video to get started with automated accessibility tests in Azure pipelines. Please note that these samples are applicable to web projects that have UI automation tests. Benefits include,
- Automated accessibility tests run during Continuous Integration and Pull Request builds, ensuring that all code changes are free of common easily-detected accessibility issues before they go to production
- Builds can be configured to fail based on the results of the automated accessibility tests, preventing both new accessibility bugs and regressions
- Failure details and how to fix information can be viewed in Azure DevOps under Builds, making it quick and easy to investigate and resolve the accessibility issues
This repository contains sample projects (see next section Available samples) demonstrating how to implement automated accessibility testing in Azure Pipelines builds using axe-core, the same accessibility scanning engine used in Accessibility Insights for Web, and Axe.Windows, the same accessibility scanning engine used in Accessibility Insights for Windows.
The following sample projects specify the main technologies used. A team that uses comparable tools and frameworks should be able to refer to the sample and update their existing tests to incorporate automated accessibility checks.
-
Sample 1: typescript-playwright-sample:
- Useful for teams using Playwright and TypeScript/JavaScript.
-
Sample 2: typescript-selenium-webdriver-sample:
- Useful for teams using Selenium and TypeScript/JavaScript.
-
Sample 3: CSharpSeleniumWebdriverSample:
- Useful for teams using Selenium and C#.
The following may be helpful as an example of how our accessibility scanning tools have been used where the product is not based on HTML:
-
- Useful for teams developing non-browser-based Windows applications. These applications can use any language or framework.
Are we missing a sample or resource you'd like to see? File a sample request or submit a pull request!
Automated accessibility tests can detect some common accessibility problems such as missing or invalid properties. But most accessibility problems can only be discovered through manual testing. We recommend both automated testing, to continuously protect against simple types of issues, and regular manual assessments with Accessibility Insights for Web, a free and open source dev tool that walks you through assessing a website for WCAG 2.1 AA coverage.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.