Embedding Accessibility into Software Testing

As the UK Government describes, accessibility should be integral to digital service development from the start, not an afterthought. Government sites not complying with requirements could be breaking the law. 

The DWP Accessibility Manual lists a number of UK laws that require accessibility measures to be met, and the UK.gov team are running this promotional campaign to encourage compliance projects. This highlights the headline legislation: The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

It also references their own detailed guide to Understanding Accessibility Requirements. This is a comprehensive guide, covering topics like Screen Reader Testing, Designing Screens and How To Do Accessibility Testing.

Accessibility Testing: Tools and Practices

For government agencies that operate large, complex websites this is not an insignificant challenge, and so operationalising the required checking into their software testing practices offers an approach for meeting the challenge at the correct scale.

It can also be considered the primary goal of testing, not just a subtask. What could be more important for testing than services that are usable for all possible site visitors, and a site that can adapt intelligently to the myriad of different device modes using it?

Also, the testing industry is well equipped to cater for these challenges. For example, Leonardo Faria writes a very detailed walkthrough of using the Axe tool for testing accessibility compliance of websites and their components, and in this video, Jon Oliver explores combining it with Cypress, a popular testing tool, for automated testing of accessibility.

In their How It Works section Cypress explain their unique software architecture and suite of testing services that make it the ideal tool for web UI testing. Clearly, the web UI is a fundamental component of an accessible user experience, so testing their operations using the right type of tools for that purpose is a primary method for assuring accessible sites and services.

With testing already being a very well established team and/or process then it’s also the simplest and quickest way to activate the capability, achieved simply through expanding the remit of what functionality is tested for, using the best tools for that purpose.

An excellent example of these tools is the Microsoft Accessibility suite including Insights, a browser extension that helps developers find and fix accessibility issues in web apps and sites.

2i Services: Accessibility Audit

In his DevOps.com blog, Brad Henry describes five ways to embed accessibility into your development pipeline, so that the practices described here can be formalized into your team operations in such a way it becomes a default capability.

This requires policy, automation and accountability enhancements so that accessibility is a well-understood expectation and that the team is suitably skilled and equipped to identify accessibility issues and know how to expertly resolve them.

2i has helped many large clients evolve their DevOps and testing practices so that they can achieve this accessibility capability, as part of an increasing maturity that produces higher quality software faster, and we can help your organisation also accomplish this improvement.

Most important to know is that automated accessibility tools only discover around 30% of issues, so manual practices are still essential requiring suitably skilled teams. Our Accessibility Testing service provides these skills and support to develop them in your organisation, beginning with an Accessibility Audit that can identify compliance issues and formulate a roadmap for addressing them.