Why I Stopped Treating Colour Contrast as a Final Accessibility Check

Accessibility often enters a project too late.

The screens are designed. The components are built. The product is almost ready to ship.

Then someone runs an accessibility audit and suddenly the team discovers low-contrast text, unclear states, inaccessible form controls, missing labels and interactions that do not work properly for everyone.

At that point, accessibility starts to feel like extra work.

But the real problem is not accessibility. The problem is when we decided to think about it.

Accessibility is a design decision

A designer makes dozens of small decisions while creating an interface: colours, type sizes, spacing, hierarchy, button states, labels, navigation and interaction patterns.

Many accessibility problems begin inside those ordinary decisions.

Take colour contrast as a simple example. If a text colour does not provide enough contrast against its background, changing it while the design is still being explored may take a few seconds.

Finding the same problem after the design system has been applied across dozens of screens is a very different task.

The earlier we find a barrier, the more options we have for solving it without disrupting the rest of the product.

Passing a test is not the whole goal

Accessibility tools are useful, but a green “pass” badge should not become the definition of accessible design.

A product can technically meet a requirement and still create a frustrating experience.

For example, replacing every difficult colour combination with black text on a white background might improve contrast, but it can also ignore the visual language of the product.

A better design question is:

How can I remove the accessibility barrier while still respecting the purpose and identity of the design?

That shift matters because designers are not simply checking standards. We are balancing usability, accessibility, brand identity and the needs of real people.

Build the check into the workflow

One lesson I have taken from working on digital accessibility is that the best accessibility process is often the one that creates the least interruption.

If a designer has to leave Figma, open another website, copy several colour values, test them, search for alternatives and then return to the design, accessibility starts to feel like a separate task.

If the same feedback is available while the design decision is being made, it becomes part of the normal workflow.

The same principle applies beyond colour contrast.

• Check heading hierarchy while designing the page, not after development.
• Think about keyboard states while defining components.
• Write meaningful labels while creating forms.
• Consider focus, errors and feedback before an interaction reaches production.
• Test whether content remains understandable without relying only on colour.

None of these decisions needs to be treated as a separate accessibility project. They can simply become part of good product design.

Accessibility gives designers useful constraints

Design constraints are not always limitations.

Responsive layouts, technical requirements and design systems all create boundaries, yet good designers learn to work creatively within them.

Accessibility can be treated in the same way.

Instead of asking, “How do I make this design accessible after I finish it?”, a better question is:

How can accessibility help me make a clearer and more usable design from the beginning?

That question changes the process.

It encourages clearer hierarchy, more understandable interactions, stronger visual decisions and greater consideration for how different people will actually experience the product.

The goal is not a perfect audit score

Accessibility standards give us an important baseline, but the people using the product are the reason those standards exist.

The goal should not simply be to reach the end of development and prove that we checked a list.

The goal is to reduce barriers before they become part of the finished experience.

For me, that means treating accessibility as an everyday design responsibility rather than a final-stage compliance exercise.

The best time to fix an accessibility problem is while you still have the freedom to design around it.