You already know why accessibility matters — designing for the full range of human abilities makes products better for everyone. This article covers the other half of the story: the standard that defines what "accessible" actually means, and the laws that now require it.
WCAG stands for the Web Content Accessibility Guidelines — the international standard for accessible digital content, maintained by the W3C.
Think of WCAG as a shared checklist that designers, developers, lawyers, and procurement teams can all point to. Instead of arguing about whether a checkout flow "feels" accessible, teams can test it against specific, written criteria. WCAG turns accessibility from a matter of opinion into a matter of evidence. If your product renders content on a screen, WCAG is the yardstick it will be measured against.
WCAG is organized around four principles, remembered by the acronym POUR. Every specific guideline in the standard rolls up into one of these four ideas.
Users must be able to perceive your content with at least one of their senses. If information only exists in one form — an image, a color, a sound — anyone who can't access that form is locked out.
Alt text on images gives screen reader users the same information a sighted user gets from a product photo or chart.
Captions on video make spoken content available to deaf and hard-of-hearing users, and to anyone watching in a noisy café.
Sufficient color contrast ensures text stays readable for users with low vision or color blindness — and for everyone using a phone in sunlight.
Users must be able to operate every control. Many people navigate entirely with a keyboard, a switch device, or voice commands rather than a mouse or touchscreen.
Keyboard access means every action — opening a menu, submitting a form, closing a dialog — works without a pointer.
Visible focus indicators show keyboard users where they are on the page, the way a cursor shows a mouse user.
No time traps means users can extend or turn off time limits, like a checkout session that expires mid-purchase.
Content and interfaces must make sense. A form a user can technically reach but cannot figure out is still a failure.
Clear error messages tell users what went wrong and how to fix it — "Enter your card's expiry date as MM/YY" instead of "Invalid input."
Predictable navigation keeps menus and controls in consistent places, so users don't relearn the interface on every page.
Labeled inputs make sure every field says what it wants, both visually and to assistive technology.
Content must work reliably across browsers, devices, and assistive technologies — including ones that don't exist yet.
Semantic markup means using real buttons, headings, and lists in code instead of styled generic elements, so assistive technology knows what each thing is.
Proper names and roles ensure a custom component, like a star rating widget, announces itself correctly rather than as a mystery cluster of icons.
Every WCAG guideline is assigned one of three levels. Level A is the floor: failing these criteria means some users are completely blocked. Level AA adds requirements like adequate color contrast and visible focus states. Level AAA is the most demanding tier, and some of its criteria aren't achievable for every kind of content.
Level AA is the conformance bar that most laws, regulations, and contracts point to.
AA is the pragmatic middle: strict enough to remove the most serious barriers, realistic enough to apply to virtually any product. When a policy, contract, or lawsuit says a product "must be WCAG compliant," it nearly always means Level AA.
WCAG 2.2, published in October 2023, didn't rewrite the rules — it extended them, and the additions read like a summary of where modern interfaces still fail people.
In spirit, WCAG 2.2 strengthened four areas. Focus visibility: the keyboard focus indicator must be genuinely visible, not hidden behind sticky headers or styled into invisibility. Dragging alternatives: anything done by dragging — reordering a list, adjusting a slider — needs a simple tap or click alternative for users with limited motor control. Target sizes: touch targets need enough room that users with tremors or larger fingers can hit them reliably. Reducing cognitive burden: don't make users re-enter information you already asked for, and don't lock login behind puzzles that memory or transcription problems make impossible.
The direction of the standard is clear: each version demands less precision, less memory, and less effort from the user.
For years, accessibility lived in the "nice to have" column of most product roadmaps. Two major legal frameworks have ended that era.
The European Accessibility Act (EAA) became enforceable on June 28, 2025. It requires private-sector products and services sold in the EU — e-commerce, banking, transport booking, and more — to be accessible. The EAA applies to non-EU companies too: if you sell into the European market, your product falls under it.
This is a significant expansion: earlier accessibility laws mostly targeted government websites, while the EAA reaches directly into everyday commercial products. A checkout flow that keyboard users can't complete is no longer just a UX flaw — in the EU, it's a compliance failure.
In the United States, the Americans with Disabilities Act (ADA) has been applied to websites through years of litigation. Courts have repeatedly treated inaccessible business websites as a form of discrimination, and lawsuits over inaccessible sites — retail, restaurants, banking — are a routine legal risk for companies operating in the US.
No single US law names WCAG for all private websites, but in practice, settlements and demand letters use WCAG Level AA as the benchmark. The safest position is the same on both sides of the Atlantic: meet the standard.
Accessibility has moved from a professional virtue to a professional requirement — and much of the responsibility lands at the design stage, not in code review. Practically, that means building accessibility into your everyday workflow:
Annotate your designs. Mark focus order, input labels, and heading structure in your mockups so developers don't have to guess.
Check contrast and target sizes early. Verifying color contrast and touch target dimensions at the mockup stage costs minutes; fixing them after launch costs sprints.
Test with assistive-tech users. Include people who use screen readers, keyboard navigation, or magnification in your usability studies, not just as an afterthought.
On auditing: automated checkers only catch a fraction of real problems — mostly mechanical ones, like missing alt attributes or low contrast. A manual pass with just a keyboard, and another with a screen reader, will surface issues no automated tool can find — a focus order that jumps around the page, a button that announces itself as "unlabeled."
Finally, treat unresolved accessibility issues as debt. Like technical debt, it compounds: every inaccessible component gets copied into new features. Unlike most technical debt, it carries legal exposure and excludes real people from your product every day it exists. Paying it down early is cheaper in every sense.
WCAG defines what accessible means; the law now defines when you must meet it.
Learn the four POUR principles, design to Level AA as your default bar, and remember that the European Accessibility Act and ADA litigation have made accessible design a requirement of shipping products — in the EU, the US, and anywhere your users are.