Accessibility Reviews: The moment when the interface is truly put to the test
There’s a moment in many digital projects that feels like a confession: the team knows the product is “almost there”, the design matches the brand, the user stories have been covered… and then the uncomfortable question arises in the background:
“How accessible is this… really is?”
It’s not just a technical issue or a compliance checkbox. Accessibility intersects with something much more fundamental: who can actually use what you’ve built and who gets left out, even if you never explicitly decided that.
Accessibility reviews are precisely that space where the product is looked at with different eyes. A calm audit to check whether the experience holds up when people with different ways of navigating, seeing, hearing, or processing information come into play.
What an accessibility review is (and what it isn’t)
An accessibility review is a systematic analysis of a digital product to verify whether it meets a series of criteria: regulatory (such as the WCAG), technical, and experiential for people with different abilities.
It’s not just “running an online validator” or ticking the “has alt text” box. It involves:
- Navigating the interface with a keyboard, without a mouse.
- Seeing how it behaves with a screen reader.
- Checking contrasts and sizes in real contexts.
- Reviewing messages, component states, errors, and help text.
It’s also not an aesthetic judgement. An interface can be visually impeccable and, at the same time, practically unusable for someone who relies on a keyboard or screen reader to work.
What it’s for (beyond avoiding complaints or fines)
Looked at coldly, accessibility usually enters conversations through three different doors:
- Legal compliance. In Europe, the EAA framework and WCAG are setting the playing field more and more clearly. In sectors such as banking, insurance, energy, or public administration, not reviewing accessibility is no longer just bad practice: it can have legal consequences.
- Real product reach. An inaccessible product reduces its own audience. It’s not only about people with recognised disabilities; it’s also about older users, people navigating with poor connections, low-quality screens, or very different usage situations ( UX Lab ).
- Quality of experience for everyone. What benefits users with specific needs usually improves the whole: clearer forms, useful error messages, visible focus, consistent patterns. Accessibility acts as a stress test for the overall experience.
But there’s something harder to measure: the implicit message the product sends. When an interface can be used with a keyboard, is well labelled, and doesn’t relegate anyone to the back seat, it’s saying: “you were in our plans from the beginning”. That, too, is design.
What gets reviewed in a good accessibility audit
Every project has its nuances, but certain blocks appear again and again.
1. Structure and navigation
The first thing put to the test is the skeleton:
- Does the heading hierarchy (H1, H2, H3…) make sense?
- Does the tab order follow the visual logic?
- Can the page be understood by reading only the headings?
- Is navigation predictable across all sections?
This is where classic problems usually surface: out-of-order elements, menus that jump erratically, missing keyboard shortcuts.
2. Focus and keyboard use
An accessible interface does not assume a mouse:
- Focus must be clearly visible at all times.
- Buttons, links, fields, and controls must be reachable with the Tab key.
- Complex components (accordions, modals, dropdowns) must be prepared for keyboard and screen reader use.
This is a point that quickly reveals whether the design system is ready for more than just clicking.
3. Colour, contrast and readability
Here we land on what often remains theoretical:
- Sufficient contrast between text and background.
- Reasonable minimum typography sizes for continuous reading.
- Elements that do not rely solely on colour to convey state (error, success, selection).
When a review reveals grey text on light backgrounds, buttons that disappear in sunlight, or tiny labels in complex forms, it’s not just talking about accessibility: it’s questioning the overall readability of the product.
4. Screen readers and labelling
The screen reader experience is an X-ray of the code’s semantics:
- Do elements have the correct roles (button, link, heading)?
- Are forms properly connecting labels and fields?
- Are state changes (errors, results, messages) announced correctly?
- Are modals and dialogs announced and does focus return when closed?
This shows whether the product was built as a collection of visual boxes or as a structure that also makes sense without seeing the screen.
5. Forms, errors and help text
Reviews also zoom in on:
- Clear error messages, correctly associated with the failing field.
- Indications of what is required and what isn’t.
- Examples that help users fill fields correctly the first time.
- Confirmations that explain what has been done after submitting a critical form.
These are details that especially help people with cognitive difficulties, but make the experience kinder for any user.
A way to measure how far the design really goes
A well-conducted accessibility review is not against the team. It’s not a list of reproaches, but a mirror that shows how aligned design, content, and development are with the reality of the people who will use the product.
Often, the conclusions of an audit don’t stop at “increase this contrast” or “add this label”. They open deeper conversations: about how error states are managed, how complex processes are explained, or how components are documented.
In that sense, accessibility is not just an external requirement. It’s an opportunity to create a more solid, clearer, and more respectful product with people’s time and abilities. And that, beyond standards, is a fairly reasonable definition of what any good digital design should aspire to be.
This is a translation of the following article from our corporate website:
