Making Non-Compliant Products Accessible: A How-To

Introduction

If your product is already live and you have just realised it might not be accessible, welcome to the conversation most teams have too late. Accessibility rarely gets designed in from the start. It gets bolted on later, if at all. And “later” has a way of never arriving.

Consider the scale of who that affects- WHO estimates 1.3 billion people, about 16% of the global population, live with some form of disability. Many of them are online, trying to use products like yours. And yet, according to the 2025 WebAIM Million report, 94.8% of homepages still have detectable WCAG failures. Six years of industry-wide effort has moved that number by just 3.1%. The gap between intent and reality is wide, and most of it stays invisible to the people building the product, until someone runs an audit and it very much isn’t.

This blog is a practical how-to for teams starting from non-compliant: how to audit what you have, fix it at the source, and build it into your system so it does’nt unravel later.

What Is WCAG, and What Are You Being Measured Against?

Before you can fix what is broken, you need to know the standard you are fixing it against. WCAG — the Web Content Accessibility Guidelines — is the global benchmark for digital accessibility, built around one premise: your product should work for people not using it the way you tested it. Without a mouse. Without the ability to distinguish certain colours. With a screen reader doing all the reading.

That is not a small group. Around 2.2 billion people globally live with some form of visual impairment. 1.5 billion with hearing loss. 1 in 7 with a cognitive disability. These are a meaningful share of your actual user base, and your product is likely failing them in ways you have not measured yet.

The Four WCAG Principles (POUR)

Perceivable — content cannot rely solely on colour or vision to communicate meaning
Operable — fully navigable by keyboard, not just a mouse
Understandable — behaviour is predictable, errors actually helpful
Robust — holds up across browsers, devices, and assistive technologies

The Three Conformance Levels

Level A –  the floor. Failures here actively block users from using your product.
Level AA – the practical target. Most legal requirements and enterprise contracts reference this level.
Level AAA – the gold standard, worth pursuing on your most critical flows.
For most teams making a non-compliant product compliant, WCAG 2.1 AA is the right goalpost. That is what the following steps are built around.

Step 1: Run a Real Audit

Most teams think they have done an audit because someone ran Lighthouse and the score was not terrible. That is not an audit. Automated tools catch somewhere between 30 and 40 percent of accessibility issues. The rest only surfaces when a human actually tries to use the product without the things most of us take for granted.

Automated Testing

Tools like Axe DevTools, Lighthouse, and WAVE catch obvious failures fast. Run them across your key journeys, not just the homepage.

Manual Testing

Put the mouse away. Tab through the product, check focus order, zoom to 200%, and try completing core tasks with only a keyboard. These are the things no plugin will ever surface.

Assistive Technology Testing

This is the step almost everyone skips. Use NVDA or JAWS on Windows, VoiceOver on Mac and iOS, TalkBack on Android. Navigate your core flows and listen. Unlabelled buttons and broken landmark structure become immediately obvious when you have to hear them announced.

Step 2: Prioritise What You Find

After a thorough audit, you will have a list and it will feel overwhelming. Not all violations are equally urgent.

Cut through it by thinking about two things: how badly does this violation block someone, and how many screens does it affect?

Fix immediately: Level A violations on core flows (login, checkout, form submission). Users relying on assistive technology cannot complete these tasks when they are broken.
Fix in the next sprint: Level AA violations on high-traffic screens: contrast failures, missing form labels, modals that trap keyboard focus.
Plan and track: Edge cases, lower-traffic screens, AAA criteria. Track them, but do not let them stall the critical fixes.

One thing that makes a real difference: write actionable tickets. “Accessibility problems on the login page” is not a ticket, it is a vague worry! “Password field missing a programmatic label – fails WCAG 1.3.1 – fix: add <label> with matching for / id” is something a developer can close the same sprint.

Step 3: Fix the Component, Not the Screen

This is the part most teams get wrong.

When you fix an accessibility issue on one screen without touching the underlying component, it comes back. The next designer using that button inherits the same broken focus state. The next input built from that component has the same missing label. Fixing the symptom without fixing the source is just deferring the problem.

Colour and Contrast

WCAG requires 4.5:1 for body text and 3:1 for large text and UI components. Check every pairing — brand colours, disabled states, placeholder text, focus rings, error states. Fix failures at the token level. If your system uses semantic tokens (as covered in our previous post on design tokens), one update propagates everywhere.

Focus States

There is almost certainly an outline: none in your global CSS — added to clean up focus rings and never revisited. Remove it. Replace it with a real, styled focus indicator defined as a shared token so every interactive component inherits it.

Semantic HTML and ARIA

A <button> is keyboard accessible and screen-reader friendly by default. A <div> that looks like one is not. Use the right elements. When a custom component genuinely needs ARIA, use it, but not as a substitute for correct HTML.

Forms

Forms are where the most failures live, and the impact is highest. A broken form is not a degraded experience, it is a door that will not open. Every input needs a real label, not a placeholder that disappears when someone starts typing. Error messages need to say what went wrong and how to fix it. Required fields must be marked in code, not just with a red asterisk.

Images and Media

Alt text describes what an image communicates, not what it looks like. Decorative images get alt=””. Charts get a description of the data. Videos need captions, audio needs transcripts. Level A, not optional.

Step 4: Make It Stick

Fixing your current violations is the easy part. The harder problem is making sure the same issues do not quietly reappear once the team has moved on.

In Figma

Build accessibility into the component such as – focus states, screen reader labels, touch target guidance and not a separate file that gets forgotten. If a developer opens the handoff and cannot see what an element announces to a screen reader, it will not make it into the build.

In the Component Library

Every component should have an accessibility section alongside its props and variants. Wire up @storybook/addon-a11y and add checks to your CI pipeline so violations get caught before they merge.

Across the Team

It only holds if it is part of everyone’s definition of done. This is not one person’s job, not a QA checkbox. The moment it becomes a post-sprint afterthought, the debt starts building again.

Key Takeaways

• WCAG 2.1 AA is your target,  Level A failures block real users and there is no good reason to ship with them.
• A real audit needs all three layers: automated tools, manual testing, and assistive technology testing.
• Prioritise by severity and breadth. First fix what blocks core journeys first.
• Fix the component, not the screen! Page-level patches do not hold.
• Semantic tokens make accessibility fixes faster , one change cascades everywhere.
• Accessibility that only lives in a one-off audit will only ever produce one-off fixes.

Conclusion

Treating accessibility as a compliance exercise is exactly what keeps it at the bottom of the backlog. Something you address when a client asks or a regulation demands it, not something built in by default. That framing is the root of the problem.

The business case is clear: people with disabilities in the US alone hold close to half a trillion dollars in disposable income, yet 69% of disabled consumers leave sites they find hard to use and 83% stick to sites they know work for them. ADA digital accessibility lawsuits crossed 5,000 in 2025. This is not a niche concern.

The products that get this right stopped treating accessibility as a separate workstream. It is in the token, the component, the handoff spec, the CI pipeline; not something anyone has to remember, because it is already there. Getting from non-compliant to compliant takes real effort the first time. Keeping it that way just takes consistency.

Ready to build accessibility into your design system from the ground up? Explore how TO THE NEW approaches Experience Design .