In the previous post, I have covered a few points for getting started with web accessibility, in this one I am going to cover how you can easily set up an A11Y development environment, how you can measure and report your progress and finally a few ways to automate reporting.

Start small.

Getting started with accessibility may seem hard and challenging, especially for teams that are maintaining a legacy codebase.
Besides learning the fundamentals of accessibility regarding HTML, JavaScript or even designing resilient user interfaces you have to start by establishing a solid working environment, incorporating some tools for yourself and your colleagues.
You can start by obtaining, measuring, reporting and finally progressively moving toward a more accessible codebase.

Devtools

Edge, Firefox Safari and Chrome have an inspection mode that provides access to important information exposed to assistive technologies on the current page via the accessibility tree. You can use them to track down any issues, errors or bottlenecks during development.

Linting

For legacy or fresh codebases, you can use linting to detect and prevent common accessibility issues. Using linting with standalone tools or ESLint plugins can you started right away. Furthermore, you can also establish a common communication language regardless of accessibility within your team.

• React A11y is an ESlint plugin for JSX
• Vue A11Y is a community driven collection of tools for Vue
• eslint-plugin-react-native-a11y works great with React Native projects

Reporting

Reporting the status and the health status of your codebase can be critical, especially for distributed teams. Using the tools above you can track down your progress, set up goals and make estimations about your upcoming releases.

• Pa11y is a command-line interface utility that reports accessibility issues.
• Tenon is an online crawler that provides instant feedback for 508 and WCAG 2.1 issues.
• The Web Accessibility Evaluation Tool is an accessibility browser extension widely used among developers.
• Lighthouse is a standalone browser extension that produces in-depth reports for accessibility issues.
• a11y.css is a bookmarklet for reporting issues regarding CSS.

W3C has also a great list of online services and web accessibility evaluation tools.

Automate the process

Reporting can get frustrating at some point, especially for teams than ship to production regularly. Reporting and linting can get automated though, using a CLI tool can easily get integrated with your CI/CD workflow. Additionally, tools like Lighthouse work great with git-hooks.
You can even add accessibility checking and reporting within your bundling process upon deployments, accessibility-webpack-plugin is a great example of doing so. Last but not least there are some great tools like accesslint that can work with GitHub's pull requests.

Testing

Testing is always a priority for development teams, adapting a workflow for accessibility testing should be established and is critical during the development lifecycle.

• AxeCore is an automated module for end-to-end accessibility tests developed by Deque Systems. You can use AxeCore straight away with Selenium Jestor or Puppeteer. -Automated Accessibility Testing Tool or AATT is also an option for end-to-end automated testing. AATT is developed and used by PayPal.
• The A11y Machine or a11ym is an automated accessibility testing tool which crawls and tests pages of any Web application to produce detailed reports.

Manual testing

The GDS Accessibility team found out that only ~30% of issues are found by automated testing, thus automation is always a strategy but manual testing can enhance your end users' experience. Testing with a screen reader should form part of your accessibility tests.
Please note that browser/screen reader combinations matters. It is recommended that you test your application in the browser best suited to your screen reader of choice.
Some commonly used screen readers/browser combinations can be found below:

• NonVisual Desktop Access or NVDA is an open source Windows screen reader that is widely used along with Firefox.
• VoiceOver is a popular integrated screen reader on Apple devices along with Safari.
• Job Access With Speech or JAWS is a prolifically used screen reader on Windows and IE/Edge.
• Window-Eyes is also commonly used with IE and Edge.
• ChromeVox is an integrated screen reader on Chromebooks and is available as an extension for Google Chrome.

Final thoughts

Getting started developing or designing with accessibility in mind sometimes looks like a headache, especially for teams that work together for a long time and have already established some fundamentals, tools or a common communication language. Luckily though, you can follow some small steps at the beginning and gradually adopt a more "accessible" way of developing, designing or testing. More than ever we can use a plethora of services and create a better more open Web for everyone.

This tutorial was originally posted on my blog.