WCAG: a boring acronym that will protect you from lawsuits

Open your product and try to reach your target action without using a mouse. Just Tab, Enter, Gunners. If you swear in a minute, congratulations, you have a typical modern interface. And a potential lawsuit is included.

The WCAG is seen as a boring document for government websites and hospitals. In practice, it is the only international standard that courts, regulators, and large customers refer to when deciding whether or not your interface discriminates against users. In the U.S., ADA lawsuits for inaccessible sites are in the thousands a year. In the EU from 2025, the European Accessibility Act applies not only to the public sector, but also to commerce, banks, e-commerce, tickets, e-books. In Russia, this is less often mentioned, but as soon as you make a product for a foreign market or for a large B2B client with a compliance department, WCAG flies into the requirements itself.

And then the pain begins. The designer learns about the availability a week before the release, the front screws the aria-label on all the buttons in a row, the product says “well, OK, let’s roll.” Six months later, a letter from the client’s lawyers or a screenshot from Axe with 400 errors arrives. It was cheaper to do it right away.

## What is WCAG really about

WCAG is not a "law." These are the W3C guidelines referenced by the laws. By itself, it does not oblige you to anything, but its requirements are sewn into the ADA (USA), EAA (EU), AODA (Canada, Ontario), in public procurement almost everywhere and in the contracts of large corporations.

The structure is simple, and it is useful to keep it in mind:

• ** Four principles (POUR): Perceivable, Operable, Understandable, Robust. Perceivable, manageable, understandable, sustainable.
• ** Levels of compliance:** A (minimum, without it at all impossible), AA (working standard, it refers to most laws), AAA (for critical scenarios – medicine, public services).
• **Versions: ** 2.1 is the most common option. 2.2 - current current, added requirements for focus, drag-and-drop, pressing purposes. 3.0 - in development, it is early to prepare, but it is worth watching.

The target level for a commercial product is almost always AA at 2.1 or 2.2. Not A - it's too minimal. Not AAA - it often conflicts with actual design.

## Who needs it at all – and why it’s not blind

The main anti-pattern in the team’s head is “Availability = Screenreaders = Blind Users, we have 0.1% of them.” That's a convenient lie.

The WCAG defends a much broader group:

• People with low vision, color blindness, age-related loss of clarity - this is tens of percent of the audience after 40.
• People with motor impairments, tremors, temporary arm injury — anyone with a cast.
• Cognitive features: dyslexia, ADHD, fatigue, not the native interface language.
• Situational limitations: bright sun on the screen, noisy subway, one hand occupied by a child, slow Internet.

The last point is the one to which products respond. An accessible interface is an interface that works in poor conditions. There are always bad user conditions.

### Questions for product review

• When was the last time someone on the team had a keyboard fly?
• Do you know the contrast between the main text and the background – the number, not “seems normal”?
• If you turn off all the colors and leave the grayscale, do statuses, errors, active elements remain clear?
• What happens if the user increases the font in the browser to 200%?

If the answer to half the questions is “don’t know,” you don’t have a problem with WCAG, you have a problem with the fact that accessibility isn’t built into the process.

## Contrast: the most common and cheapest mistake

This is the first thing that automated scanners and lawyers cling to. And the first thing that designers break in pursuit of “airiness”.

Basic AA numbers worth learning by heart:

• Normal text: contrast at least 4.5:1 to background.
• Large text (from 18pt ordinary or 14pt bold): 3:1.
• Icons, controls, input boundaries, focus states: 3:1 to the adjacent background.

The light grey placeholder on white, the pale blue reference, the thin border of the input color #E0E0E0 are all classic flops. On the layout in Figma looks elegant, on a laptop in a cafe during the day - not read at all.

### Checklist by contrast

• In the main body text, the contrast ≥ 4.5:1 is checked by number, not by eye.
• Placeholders in inputs are not used instead of labels and are themselves 4.5:1, or the label is always visible separately.
• The boundaries of the input fields and checkboxes have a contrast of ≥ 3:1 with the background shape.
• The focus state is visible on all interactive elements and is also 3:1.
• Disabled states don’t have to be contrasted, but don’t have to look enabled.
• In a dark topic, contrast is tested separately – it’s not the same as light inversion.

Anti-pattern: A design system with a single palette of text/text secondary/text tertiary, where tertiary has a contrast of 2.8:1. It's going to get into hints, metadata, timestamps -- and put the whole product in AA. It is treated once at the token level, then does not return.

WCAG is not a charity or a checkmark for the public sector, it is a legal and product standard that is easier to build into the design system now than to redo the product for audit later. Next, we will analyze keyboard navigation, forms, media and how to build verification into the workflow so that accessibility is not an emergency before release.

## Keyboard navigation: a test that almost no one passes

Take your product, put down your mouse and try to pass the key script with Tab, Shift+Tab, Enter, Space and arrows. Most teams do this for the first time on a tester review and experience an unpleasant shock.

What usually breaks:

• Custom dropdowns and combo boxes collected from div do not respond to arrows and Esc.
• The modulators don't catch the focus inside, and Tab drives off to the background under an overlay.
• After the poppa closes, the focus flies to the beginning of the page instead of returning to the button that poppa opened.
• In the pictures-links focus is, but visually not visible: the designer removed outline for aesthetics and did not draw anything in return.

### Keyboard checklist

• All interactive elements are attainable by Tab in logical order (left to right, top to bottom).
• The visible focus is always there – and it does not coincide with the hover, so as not to confuse states.
• Models and popovers catch the trick, bring it back, close on Esc.
• Custom controls (toggle, select, tab) work according to the expectations of browser analogues.
• Skip-link “to the main content” is on the pages with a heavy hat menu.

If you don’t have a token in your design system and a focus ring specification, this is the first hole through which half of the WCAG points escape.

## Shapes: The Place Where Accessibility Breaks Most Costly

A form is a contract with a user. If he doesn't understand what's wrong, he leaves and doesn't come back. WCAG here coincides with the basic UX.

Anti-patterns that occur in almost every second form:

• Placeholder instead of label. The user started typing - the prompt is gone, the context is lost.
• The error is transmitted only by color: a red frame without text and without an icon. The color blinder and the screen reader won't get it.
• The error message lives visually next to the field, but in the markup is detached from it - the screen reader will read the "input" and silence.
• Required fields are marked only with an asterisk without explaining what it means.
• Autofocus when a page loads jumps into the middle of the screen and breaks the orientation.

### What to put in the layout of the form

• A visible label over the field, always.
• States: default, hover, focus, filled, error, disabled - drawn as separate elements of the design system.
• The error text is near, specific (“enter email in name@domain format”), not “error”.
• Duplication of meaning: color + icon + text. Any two out of three is a minimum.
• The hints and descriptions are tied to the field through the specification for the developer, rather than “hanging nearby.”.

## Media, traffic and autoplay

Pictures without alt, video without subtitles, animation that does not stop - these are the three classic claims in any audit.

Rules that are easier to keep at the process level than to fix later:

• Each meaningful picture has a text description. The decorative one has an empty alt so that the screen reader will miss it.
• Video of the speech -- subtitles. Not "autogen on YouTube", but read out.
• Animation longer than 5 seconds and any blinking - with the ability to disable, and respect for prefers-reduced-motion.
• Carousels that flip themselves are almost always a bad idea. If you don’t, you need a clear pause.

## How to build this into the workflow

The main mistake is to give access to one "responsible for the a11y" at the end of the sprint. This does not work: by the time of the audit, the layouts are already folded and it is expensive to redo.

What works in practice:

### At the design-system level

• The contrast of all text tokens is verified and signed in Figma.
• Focus style is a separate component or effect, not “draw in code”.
• The size of the goals of pressing at least 24×24 (and preferably 44×44 for mobile) is laid in buttons, icons, checkboxes.
• The dark theme is tested separately, not inverted.

### At the layout level

• The designer applies tab order and focus states to key screens.
• Error and empty-state scenarios are drawn along with the basic flow, rather than “residual.”.
• The contrast plugin is launched before the transfer to the development, not after.

### At the team level

• In the definition of done feature has the item "passes from the keyboard and checked in the screen reader at least superficially.".
• Automatic scanner (axe, Lighthouse, analogue) is connected to CI and does not allow regression deplosion.
• Once a quarter, the team sits down and goes through a real-life scenario with a person who uses assistive technology. One such hour changes priorities more than ten reports.

## Questions for review layout

• Is each state of the interactive element drawn separately?
• Do forms have error patterns, not just a “successful path”?
• Text tokens are signed in contrast to the background on which they are used?
• If all colors are removed from the layout, do the hierarchy and statuses remain clear?
• Is there a focus style in the layout or will the developer come up with it?

The short summary of the segment: availability is not made a heroic audit before release, it is made a little bit in every layout, token and component. Next, look at verification tools, automation, AI assistants, and where their promises diverge from reality.

## Testing tools: what really catches the problem

Automation finds about a third of WCAG violations. That's a lot - but it's not "one-button availability." Everything that is connected with meaning (adequate alt, understandable error, logical order of reading), the machine will not appreciate.

Rough hierarchy by what is caught:

• Linters and scanners (axe, Lighthouse, Pa11y). Contrast, missing alt, id duplicates, unlabeled fields, violation of header structure. Quick, cheap, CI.
• Plugins in Figma. Token contrast, checking pairs "text against the background", simulation of color blindness. Useful at the layout stage, before the code is even written.
• Manual keyboard check. Tab, Shift+Tab, Enter, Esc, arrows. If the focus is lost, jumps into an invisible area or gets stuck in a modal, you can see it in a minute.
• ** Screen reader.** VoiceOver on Mac/iOS, NVDA on Windows, TalkBack on Android. One passage through the float reveals almost all semantic problems: nameless buttons, torn errors, endless “image, image, image”.

If you choose one action that gives the maximum is ten minutes with the screen reader on your product. The effect is sobering.

### Anti-pattern: "We have Lighthouse 100, we're available"

Lighthouse 100 means you don’t fail automatic tests. That's it. A button with the text “More details” without context, a form where the error is not associated with the field semantically, a modular from which you can not leave Esc – all this calmly passes the scanner.

## AI assistants and accessibility: where they help, where they lie

LLM and plugins in Figma/VS Code already generate alt, rewrite error messages, offer aria attributes. But it is a tool to amplify, not replace, the review.

### What is wise to delegate AI

• A draft of alt-texts for an illustration library - then the designer or editor passes and rules.
• Rewriting system errors into human language ("enter email in name@domain instead of invalid input").
• Explanation of which ARIA pattern fits a specific custom component, with reference to the specification.
• Initial layout analysis: "find potential accessibility issues on this screen" - as an extra pair of eyes.

### Where AI consistently fails

• Hallucinations with ARIA. The model confidently suggests aria-*, which does not exist, or combinations that break semantics. Any ARIA recommendation is checked by specification rather than taking its word for it.
• Context of the product. AI doesn’t know what you have “Save” in this float is actually “Send an application to a lawyer.” Alt and labels without context are generalized and useless.
• The model sees the layout as a picture, not as a tree. Tab-order and logic navigation she guesses, and often by.
• MCP integration with Figma. When an agent manages the “more accessible” layout, it easily breaks the tokens and fortunes you’ve built. Changes from AI to review are as strict as PR from Jun.

Working model – AI prepares options, the person makes the decision. Not the other way around.

## How to explain the decision to the team

Accessibility is rarely cut because everyone is against it. More often than not, it is cut because its value is not articulated in the language the product and business hear.

What works in conversation:

• Legal risk. One public lawsuit or regulatory order is more expensive than a year of work on a11y. In B2B-tenders, the VPAT/accessibility statement is increasingly a mandatory document – without it, they simply do not allow it.
• Persistent visual, motor, hearing impairments, plus situational (bright sun, broken arm, noisy subway) are not a niche group, they are a significant share of any mass audience.
• Quality as a side effect. Teams that keep the bar on availability tend to make both clearer shapes and more stable components. This can be seen on the review and in the bugs from the support.
• ** Cheaper at the beginning.** The token contrast works in a minute in the design system and a week after the redesign on the market.

### Questions to Ask at the Fichi Review

• What happens to this screen if the user can’t see the color?
• How does this fly just from the keyboard?
• What will the screen reader read on the main button?
• Does every state (download, error, empty) have a clear text, not just an icon?
• If the feature is rolled out tomorrow, what will be written in support of us first?

The short summary: automation catches the rough, AI accelerates routine, but the team carries the semantic decisions and arguments itself. Next, how to put all this into a sustainable process and what to take first, if you start from scratch.

## The minimum checklist you can start with tomorrow

If you don’t have any accessibility process at all, don’t write a quarterly strategy. Take this list and go through it on one key float - onboarding, payment, the main action of the product.

### Design layout

• The contrast of text to background is checked on all states, including hover, disabled, placeholder
• Color is not the only carrier of meaning (the error is not only red, the status is not only a green circle)
• The size of the touch target on the mobile is no less comfortable for the finger, between neighboring targets there is a gap
• Each button icon has a text signature or an explicit aria-label in the speck
• Focus states for all interactive elements, not just hover
• Forms: each field has a visible label, errors are described by text, not just the color of the frame
• Modals and overlays: the layout describes how to get out of them and where the focus returns

### Code and assembly

• The page has meaningful <title> and language in <html lang>
• Headings go hierarchically, without jumping from h2 to h5
• Images that carry meaning have alt; decorative – empty alt
• The button is <button>, the link is <a>, not <div onClick>
• The shape goes from top to bottom without surprises, the focus is always visible
• Esc closes modal, focus returns to trigger element
• Dynamic messages (toasts, validation errors) are declared to the screen reader via aria-live or a role

### Review and release

• In the PR template there is a clause about the a11y, even if just "checked with the keyboard"
• Before the release, the feature once passed screen reader – VoiceOver, NVDA or TalkBack
• The design system has available combinations of tokens, not just a palette
• In the criteria for the acceptance of the task, keyboard scripts are prescribed

## Anti-patterns on which even mature teams burn

### Let’s make a separate version available

The parallel simplified version of the site lives exactly until the first redesign of the main one. Then it lags behind, breaks down, and becomes worse than it would be without it. Accessibility is built into the main product or not built into it.

### The Skip Link That Leads to Nowhere

“Go to content” is a good idea if the focus after it actually hits the beginning of the content. Often there is a link and the focus stays in the header because the target block does not have tabindex="-1" and focus control. It is better not to have a skip link than to have a non-working link.

### Aria on top of everything

When the team learns about ARIA, it is tempting to wear every component. role="button" on the button, aria-label on top of visible text that does not match what is written on the screen, aria-hidden on interactive elements. The first rule of ARIA is not to use ARIA if there is a native HTML element that does the same.

### Accessibility as a one-person task

"We have Masha, she's about a11y." Masha goes on vacation - and the features go without checking. Availability only works as a shared responsibility: the designer lays down, the developer implements, QA checks, the product does not cut.

### Testing only with your mouse

The team looks at the layout through the eyes of a healthy sighted person with fast internet and a new laptop. Any unusual context – the system magnifier, enlarged font in the browser, navigation only with the keyboard, mobile in one hand – opens a layer of problems that is not visible on the review.

## Questions for code review and design review

These questions should be sewn into a template so that they are asked by default, not when someone remembers.

### To the design review

• Where is the state of focus in this layout and how is it different from hover?
• What happens if the user has a system font of +50%?
• How does this component look and sound in a state of error, load, empty result?
• If you remove all the colors and leave the gray scale, does it make sense?
• What should be read aloud when hovering over this icon?

### To code review

• Is it possible to reach the main action only with the keyboard?
• What role does this custom component fit and is it validated by the specification of ARIA patterns?
• Where does the focus go after closing the modular, deleting the list item, sending the form?
• Are all dynamic changes important to the user declared assistive technologies?
• Does the field have a visible link to the label and error message via for/id or aria-describedby?

## What to do first if you start from scratch

The order that usually gives maximum effect with minimum resistance:

1. Fix contrasts in the design system. This is managed centrally and closes a whole class of violations at once.
2. Put the focus in order: visible, predictable, not lost in modals.
3. Pass the main flow keyboard and record anything that breaks.
4. Turn on the screen reader on the same flow. This is the point where the team usually decides that accessibility is not a theory.
5. Suture items about a11y into task templates, PR and readiness determination.

Then we can talk about regular auditing, training, VPAT and integration with CI. But without the first five steps, everything else is paper.

Availability is not about perfect WCAG compliance down to the last letter. It’s about your product continuing to work when the user conditions are different from the designer’s. And the fact that on the day when a lawyer or tender comes with an accessibility statement, the team has something to show, not three weeks of convulsive patching.