ACCESSIBILITY
8 MINS
How do you build accessibility into a product that’s already live?
If your product is already live, accessibility can feel like something you’ve missed your chance to do right.
This piece breaks that myth and walks through what teams can still fix mid-cycle, practically and intentionally, without starting over.
Start with incremental fixes
Use automated scanning tools
Tools like axe, Wave or Lighthouse can help catch a portion of common issues like missing alt text, low contrast and so on.
b. Do manual accessibility testing
Increase your browser’s text size or use zoom to see if layouts are breaking to check for responsive or text-scaling issues.
Navigate your app using only a keyboard to make sure all interactive elements can be reached and used without a mouse.
Test with screen readers like VoiceOver, NVDA or Talkback to check that content is announced in a logical order, images have appropriate descriptions, forms and buttons are labelled correctly, and all errors are conveyed with audio.
You can also consider other assistive tech, like screen magnifiers or high-contrast modes, for a more thorough evaluation.
c. Evaluate the issues against accessibility standards
This way you can eventually arrive at a point where you’re meeting Level AA compliance, which is the typical legal baseline.
d. Prioritise your fixes
This will make the usability experience much better with minimal disruption. These could be adding missing alt text, or fixing the heading structure, boosting the color contrast or improving screen reader support.
e. Execute a triage-based rollout
Have a triage roll-out where critical issues and blockers get fixed immediately, and then larger redesigns like reworking a complex widget, can be marked for later.
2. Revisit foundational design decisions
Establish clear colour meaning and non-colour cues
Make sure your product’s colour palette provides enough contrast.
If contrast is low, people quite literally can’t read or identify what’s interactive, especially outside ideal conditions.
There should be enough contrast between:
the text and the background
interactive elements and their surroundings
The recommendation from WCAG guidelines is at least a 4:5:1 contrast ratio for normal text and 3:1 for large text. Falling short here affects users with visual impairments, and also makes content harder to read for other users in low light, on older screens or even when someone is fatigued.
While your core palette holds brand colors that are more about emotion and identity, functional colours focus on usability and help with visual cues like errors, alerts and background distinctions. Similarly, having an extended palette helps with different states.
b. Use contrast checkers on real UI elements
Running a contrast checker on sample screens isn’t enough. Contrast needs to be checked where it actually matters: primary buttons, secondary text, helper labels, error messages, and disabled states.
This is important because contrast failures are often contextual. A colour might pass against white, but fail against a tinted card background. Or it might work for large headings but not for body text.
Checking contrast at the element level helps you catch these mismatches early, instead of discovering them later through audits or complaints.
On LinkedIn, A Paytm user flagged a legibility and contrast issue being faced by his mother while using the app. The team responded with the fix below. (Source)
c. Fix colour issues where they originate, the token layer
Before you change anything, list and inventory all colour tokens currently used, and where they’ve been used, such as text, backgrounds, borders, icons, charts, and states like hover, active, disabled, and error.
This will show where the same tokens have been used for multiple purposes, like text, decoration and system states.
d. Replace raw colour values with meaning-based tokens
For instance, if your system relies on tokens like this: <blue-500>, <red-300>, or <grey-700>, then, colour meaning lives in people’s minds. Someone has to remember what each colour stands for. And that memory won’t stay consistent across teams or time.
In an accessible design system, the colour token architecture describes purpose and should look like this: <text-primary>, <text-secondary>, <action-primary>, and <status-error>.
Google's Material Design 3, released in 2021, introduced a refined color system based on semantic tokens like color-primary and color-on-primary. These tokens allow for flexible theming (like light/dark mode) and ensure accessibility through contrast-aware design. This token-based system is used across Google's ecosystem—including Gmail, Google Drive, and Android—helping teams scale design consistently and maintain visual coherence across products.
e. Use semantic tokens and test them in pairs
Tokens like Primary, Success, Warning, Error are only useful if they work in the contexts they’re used in. That means testing token pairings, not individual colours.
For example:
does <
status-error-text> meet 4.5:1 against all approved surfaces?does <
text-secondary>ever get placed on backgrounds it can’t support
This is how teams move from “we should remember contrast” to “the system enforces it.”
f. Never rely on colour alone to convey meaning
If an input error state is indicated by a red outline, also include an icon or text message. If a button’s active state is shown by colour, also provide a shape or label change.
g. Consider offering a high-contrast theme or mode for users who need it
This is specially so in the case of apps where users often review dense data like fintech apps. A high-contrast theme with blacks/whites or high-contrast colours can greatly help low-vision users.