How to improve implementation, testing and iteration of UX design for accessibility

The role of a UX designer ensuring a good accessibility experience doesn’t stop at the development stage
Once in development there is so much more a UX designer can do for their project, and a foundational understanding of expectations is critical.
For example:
How would a screen reader understand this page?
If a user is using a keyboard, how would the page tab correctly?
How does the page scale if a user increases the point size?
If there is video content, is it captioned?
Once agreed as a team, these should be built into the Acceptance Criteria of each feature (epic, user story, whatever system you're using). At this point it is understood by all, is testable and won't get lost.
Click here for a reminder of what accessibility is, and why we should care about it.
Testing — who is responsible for checking accessibility?
You should work with your development team to ensure your intentions around accessibility are understood and interpreted correctly. You will no doubt have an approval process with your developers, so can work together on that.
Do you have a QA team? If so, they would likely take responsibility for the accessibility testing, as well as functional requirements.
The A11Y Project is a fantastic resource, set up to help designers and developers build accessible digital products. Whether you are new to the world of accessibility or have a solid awareness, the A11Y’s language and presentation is designed to make the WCAG standards more tangible. They even have a helpful checklist on their homepage, which all members of your team can reference when designing, building and testing for accessibility robustness.
How are you testing the accessibility of your app?
There are lots of tools available to check the functional accessibility of a website, which the A11Y have a long list of. At Brightec we have used PageSpeed Insights and Deque’s Axe, both which give a pretty thorough diagnostic of each page.
For apps, our QA team use built-in tools from the excellent Android Studio and, in a more limited form for iOS, Xcode. These can also help your developers as they build to check as they go. At the moment though, it is far harder to run an automated test on an app than a website as most automated testing tools, for the most part, cannot access the codebase. There are a few which can, but come with a hefty price tag.
However good your automated tooling is, the results only account for 20–30% of accessibility testing. Nothing beats a structured manual test. At Brightec, we have a rigorous procedure in place whereby we combine automated and manual testing to check our apps against all relevant WCAG criteria.
We also offer that service to clients post-production — you can find more about our EAA Audits service here.
It is inevitably more onerous to implement accessible standards retrospectively, but with the European Accessibility Act enforceable from June 2025 it is perhaps unsurprising that lots of companies are again looking at their existing products.
How to maintain accessibility as you iterate and grow your product
Once you have systems and standards established it is far easier to maintain accessibility as you grow your product than when getting started..
Document well, set up your design systems thoroughly, template your acceptance criteria, communicate the message to the appropriate stakeholders, and continue to ensure you are on top of current guidance.
Your client and their customers will thank you for this hard work!
External resources
In addition to the resources mentioned throughout this series, we have compiled a short set of useful resources here:
Dos and don’ts: Short, concise post by gov.uk on designing for accessibility
Series of posters created by gov.UK on designing for accessibility
Looking for something else?
Search over 400 blog posts from our team
Want to hear more?
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!