We at Centro Labs recently finished making LocalMate WCAG 2.2 Level AA Compliant.
It's not something that shows up on a demo reel or has any flashy consequences, but it's one of the more meaningful things we have shipped. Here's how we did it and what we found out while doing it.
What WCAG actually is
The Web Content Accessibility Guidelines (or just WCAG) are international standards developed by the W3C Web Accessibility Initiative (WAI) to ensure digital contents are accessible to anyone, including people with disabilities.
It applies to both web applications and mobile applications.
POUR Principles
It's centered around the four core POUR principles:
Perceivable
Information must be presentable to users in ways they can sense. This can be: Alt-Texts on images, aria labels, captions, etc.
Operable
UI components and navigation must be operable. This means: being able to tab through the content of the website, having enough time to read the contents on it, etc.
Understandable
Information and operation must be understandable, meaning: Readable text, predictable functionalities, etc.
Robust
Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
Conformance Levels
The standard is split up into three levels of compliance:
- A: Minimum level of accessibility
- AA: Medium level of accessibility. This is often required for applications in the public sector, which is sadly not met by lots of applications.
- AAA: Maximum level of accessibility
Why it matters beyond compliance
Usually when people pitch WCAG-Compliance they talk about government guidelines, legal requirements, etc. All of that is true, but its importance runs deeper than that: Roughly 15%-20% of the population has some disability, affecting how they navigate and experience the web.
A much larger group than that has situational impairments: Navigating a website on a dark screen, using a service with a sprained wrist, using a service in a second or third language.
Accessibility is not only for the permanently impaired, but also for temporary constraints in how they use those digital services.
For LocalMate specifically the reasoning is clear: It's a service that makes information and services accessible to anyone. Not complying with the WCAG AA guidelines is a contradiction to our mission.
What most websites get wrong
Designers and developers often work on their applications in a controlled environment: On a desktop with bright screens, familiarity with the language and with a deep understanding on how the UX was designed, I mean they were present when the application was written.
Below are a few key requirements that are often neglected.
1. Contrast ratios
The rule: Body text needs a contrast ratio of at least 4.5:1 against its background. For larger text (18pt+ or 14pt+ on bold text) this is eased to 3:1. This is success criterion 1.4.3.
Before we were compliant our AI disclaimer in the footer was a secondary light text on a grey background:
This is a contrast ratio of 1.75:1, making it not compliant. We swapped this for darker text, achieving compliance.
2. 400% zoom without horizontal scroll
The success criterion 1.4.10 says, that on a viewport of at least 1280px in width the website must be usable at a 400% zoom.
Most desktop-first designs don't comply: Sidebars, overflowing content, etc.
We were also not compliant before, having the input overflow and making the application unusable:
Fixing this took a bit of UX-Engineering: We turned off the minimum width on the input box and moved the "Open a new chat" button to the top of the page, disconnected from the input itself:
The easiest way to tell if your website is compliant: Try using it after zooming in to 400%.
This is what the cover image of the blog article is. The "ugly" input conserves both width and height, by getting rid of most padding on very small screens.
3. Missing or lying ARIA labels
ARIA stands for Accessible Rich Internet Applications. They are the aria-label tags that inputs and buttons often have.
They add semantic annotations for assistive technologies.
Things that are frequently missed are:
-
Icon-only buttons have no accessible names. They should all get an
aria-label, which describes the action. - Inputs with placeholders as labels. Those should also get an accompanying label.
4. Missing focus states and keyboard traps
If you can't see where the keyboard focus is, you can't use the app with a keyboard, making it non-compliant with guideline 2.4.7.
The browser default is often removed by designers (using outline: none, because it's ugly).
For compliance reasons we show an outline and, if applicable, show the hover-labels:
Keyboard traps
A keyboard trap is when a tab-cycle gets stuck in a loop, like tabbing in the footer and never getting out.
This is a no-go. For people that cannot use a mouse something like this means: Refreshing the page every time they get trapped.
This can be corrected by introducing a tabbing order on a website, even though most of the time, this should be handled by the browser.
The point
I could go on for days about other things that are frequently non-compliant, but the core message is: Don't just expect that your work is accessible, make sure it is.
Tools that helped us
Doing this manually and finding all the weak spots is annoying and takes tons of time. Luckily, there are tools to help.
Lighthouse reports
Google has a website called PageSpeed Insights. While it also covers SEO and first contentful paint, it offers a section called Accessibility, where some issues get caught.
axe DevTools
axe DevTools is a browser plugin, that allows running a diagnostic on your localhost page, catching issues before they ever reach production.
It doesn't catch all issues, but quickly points out quick-wins and obvious problems, like missing contrast.
AI Agents
Let's be honest: Most of the heavy lifting can be done by AI Agents. They can quickly scan through the entire codebase, use playwright MCPs to figure out the tabbing order, etc.
Running Claude Code in plan mode to find, explain and correct all mistakes gets you about 90% of the way there.
The uncomfortable takeaway
Most web apps aren't WCAG AA compliant because accessibility is hard to see and easy to defer. There are no actionable bug reports from the users that get left behind, because they got frustrated and left. There is almost no marketing upside, because it hardly translates into a nice pitch deck and it slows down features.
The way I have come to think about it: WCAG is a proxy, for whether a team takes non-ideal users seriously. They don't think about the person who forgot their glasses, uses the app on a phone while on the bus or someone whose first language isn't the one in the UI. If the response to any of those is: "Well I don't know, it kind of works", the product is shipping a product that divides.
Making LocalMate WCAG AA compliant took real engineering and UX time. It also surfaced lots of small quality issues that improved the product for everyone, not just users with disabilities.
This article was originally published on the Centro Labs Blog, check it out there!
