Accessibility is commonly wrapped up in other testing activities, but it is worthy of focus effort. A lot can be done to mitigate accessibility errors, by investing time at design phase and integrating checks in the CI pipeline.


Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Web App Accessibility Standards (WCAG 2.1)

Mobile App Accessibility Standards (WCAG 2.0)

Both Apple and Android is very proactive with tools and development standards of their own, based on w3 web app Accessbility standards, but with additional attention to mobile-specific challenges.

Level A

Minimum level – without addressing these items, barriers exist that cannot be overcome by assistive technology.  This level affects the broadest group with the most benefits and is essential.

Standard Level A Checks

Level AA

More accessible – With the minimum level of support, some barriers will still exist which impact certain groups of users.  The criteria at this level establish a level of accessibility which should work with most assistive technology on desktop and mobile devices.

While some apps will sail through Level AA, some may struggle - for example, an app that depends on sight to annotate an image. A first important step is to realise Acessibility is an evolving improvements exercise. Just because your app passes in Sprint 5, it doesn’t mean it will pass in Sprint 7. So treat an audit as a review. Document this in an accessibility statement, that you can keep updated, as your app progresses and improves.

Standard Level AA Checks

Level AA will be more demanding check of the app, but striving for this will improve not only Accessibility of the app, but the quality.

Contact me for further discussion about how I could help. No commitment. You may be interested in getting a comprehensive review, or assistance in putting Accessiblity testing in a shift left state, and inegrated in the SDLC.