Web Accessibility: A Practical WCAG Guide for Product Teams
Accessibility is not a checklist you bolt on before launch. This is a practical WCAG 2.2 guide for product teams who want to build it in from the start.
- Web accessibility means building so people with disabilities can perceive, operate and understand your product, and WCAG 2.2 is the standard that defines what that concretely requires.
- Target WCAG 2.2 Level AA across the product: it covers keyboard access, colour contrast, focus visibility, labels and the newer 2.2 rules on focus and target size, and it maps to most legal expectations.
- The cheapest accessibility is the accessibility you build in. Semantic HTML, real labels, keyboard support and automated plus manual checks in the workflow cost far less than retrofitting after launch.
- A short list of failures accounts for most audit findings, so fixing non-semantic markup, missing labels, poor contrast and invisible focus gets a team most of the way to conformance.
Web accessibility means building digital products so that people with disabilities can perceive, operate and understand them, and WCAG 2.2 is the standard that defines what that concretely requires. For most product teams the practical answer is short: target WCAG 2.2 Level AA, lean on semantic HTML to get most of the way for free, and pull automated plus manual checks forward into design and code review. Done that way accessibility is mostly a set of good engineering habits, not a pre-launch scramble.
This guide is aimed at teams who want the practical version, not a legal treatise. It sits close to how you already think about the stack, and if you want the broader split of responsibilities behind a web app, our overview of frontend vs backend gives useful context. Here we cover what WCAG 2.2 actually asks for, the failures that come up again and again, and how to make accessibility a habit rather than a fire drill.
What Web Accessibility and WCAG 2.2 Actually Require
WCAG, the Web Content Accessibility Guidelines, is the internationally recognized standard for accessible web content, and version 2.2 is the current release. It builds on 2.1 by adding a handful of new success criteria, most of them focused on people with motor and cognitive differences.
The guidelines are organized around four principles, remembered by the acronym POUR, and every specific rule ladders up to one of them. Understanding the principles is more useful than memorizing rule numbers, because it tells you why a rule exists and helps you make good calls in the grey areas the rules do not spell out.
| Principle | What It Means | What It Looks Like in Practice |
|---|---|---|
| Perceivable | Users can perceive the content through some sense | Text alternatives for images, captions for media, sufficient colour contrast |
| Operable | Users can operate the interface | Full keyboard access, no keyboard traps, enough time to act, no seizure triggers |
| Understandable | Content and operation make sense | Readable text, predictable behavior, clear error identification and recovery |
| Robust | Content works with assistive tech now and later | Valid, semantic markup and correct, minimal use of ARIA |
Conformance Levels and Which to Target
Almost every product team should target WCAG Level AA as its practical standard. WCAG defines three conformance levels, and knowing which to aim for saves a lot of wasted effort in both directions.
| Level | Scope | Who It Fits |
|---|---|---|
| Level A | The most basic barriers only | A floor, not a goal; necessary but never sufficient for a serious product |
| Level AA | The criteria that matter most in daily use | The practical target for the whole product; the level most laws and procurement policies reference |
| Level AAA | The strictest criteria | An aspiration for individual high-value flows, not a blanket goal for a whole site |
Target Level AA across the product and reserve AAA for individual high-value flows where it genuinely helps. Chasing AAA everywhere is a common way to burn effort without improving real-world usability.
The New Success Criteria in WCAG 2.2
Version 2.2 added new criteria worth knowing because they catch problems teams routinely ship. They are practical, and worth building into your component library once so every screen inherits them.
- Focus Not Obscured: when an element receives keyboard focus, it must not be hidden behind sticky headers, cookie banners or other overlays.
- Focus Appearance: the visible focus indicator must be large and contrasting enough to actually see, not a faint one-pixel outline.
- Target Size: interactive targets should be large enough to activate comfortably, which matters most for touch and for users with motor impairments.
- Dragging Movements: any action that relies on dragging must have a simpler single-pointer alternative, since dragging is hard for many users.
- Accessible Authentication: login should not depend on a cognitive test like remembering or transcribing a code, and should allow methods like paste and password managers.
Build the 2.2 criteria into your shared components once, and every new screen inherits correct focus, target sizing and drag alternatives without anyone having to remember them.
Not Sure Where Your Product Stands?
We can audit your product against WCAG 2.2, tell you honestly where the real barriers are, and help your team build accessibility into the workflow so it stops being a pre-launch scramble.
Common Accessibility Mistakes Teams Get Wrong
Most accessibility problems are not exotic, and a short list of the same issues accounts for the large majority of what audits find. That is good news, because fixing these gets you most of the way. The table below pairs each recurring failure with the fix that resolves it.
| Common Failure | Why It Breaks | The Fix |
|---|---|---|
| Non-semantic markup | Divs and spans with click handlers have no keyboard or screen-reader behavior | Use real buttons and anchors so behavior comes for free |
| Missing form labels | Screen-reader users cannot tell what a field is for | Associate a real label with every input |
| Poor colour contrast | Light grey on white is unreadable for many users | Meet AA contrast ratios and check them at design stage |
| Missing or noisy alt text | Images convey nothing, or decorative images add screen-reader noise | Describe meaningful images; mark decorative ones empty |
| Keyboard traps and invisible focus | Users can tab in but not out, or cannot see where focus is | Ensure focus can move freely and the focus ring stays visible |
| Icon-only controls with no name | A screen reader announces nothing useful | Give every control an accessible name |
Semantic HTML and Building It Into Your Workflow
The single highest-leverage accessibility practice is using the right HTML element for the job, and the second is catching issues where they are cheapest to fix. Native elements come with keyboard behavior, focus management and screen-reader semantics built in for free, and reimplementing them with generic elements plus ARIA is both more work and more error-prone. Accessibility then sticks only when it is part of how you build, not a phase at the end.
Reach for ARIA only to fill gaps native HTML cannot, and keep component patterns accessible by default so teams inherit correctness, an approach that pairs well with the composition ideas in our guide to React design patterns. Then run this checklist on the flows that matter.
- Use a button for actions and an anchor for navigation, and real headings in order, so the page has an outline assistive tech can navigate.
- Add automated checks to CI: an axe-based scanner and linters catch a meaningful share of issues on every build, though they find only around a third of real problems.
- Do manual keyboard testing: unplug the mouse and complete each key flow with the keyboard alone, which surfaces what automation misses.
- Run screen-reader spot checks on critical journeys to hear what your users actually experience.
- Catch contrast and target-size problems at the design stage, in the mockup, before a line of code exists.
- Put accessibility in the definition of done so it is a shared standard, not one person's crusade.
The first rule of ARIA is not to use ARIA when a native element already does the job. Incorrect ARIA actively misleads assistive technology and is worse than none at all.
Cost and Timeline Factors
The cost of accessibility is driven mostly by when you address it, not by the rules themselves. Building it in from the start is far cheaper than retrofitting after launch, because a retrofit means reworking components, markup and flows that are already shipped. The qualitative factors below tend to drive effort and timeline more than any single criterion.
| Cost Driver | Lower Effort | Higher Effort |
|---|---|---|
| When you start | Accessibility built in from design | Retrofit after launch |
| Component reuse | Shared, accessible-by-default library | One-off components rebuilt per screen |
| Product complexity | Standard forms and content | Custom widgets, canvas, rich interactions |
| Team habit | Checks in CI and definition of done | One-time audit with no process |
How Acqurio Tech Approaches Accessibility
We treat accessibility as an engineering habit rather than a pre-launch audit, because that is what makes it stick and what keeps it affordable. In practice that means semantic HTML by default, accessible component patterns your team can reuse, and both automated and manual checks folded into the workflow so issues are caught where they are cheapest to fix.
It is also worth saying plainly that accessible sites tend to be better sites: semantic, well-structured markup helps assistive technology and search engines alike, which is why a lot of accessibility overlaps with the fundamentals in our on-page SEO checklist. Clear labels, logical structure and keyboard operability improve usability for everyone and widen your addressable market. This is general guidance, not legal advice, so confirm your specific obligations with a qualified professional for your market. If you want a hand auditing your product or building this into your workflow, contact us and we will make it practical for your team.
Conclusion
Web accessibility is not a pre-launch checklist, it is a way of building that a good team can absorb into its normal habits. Aim for WCAG 2.2 Level AA, lean on semantic HTML to get most of the way for free, and reserve AAA for the flows where it truly helps. Learn the POUR principles so you can reason about the grey areas, fix the handful of failures that account for most audit findings, and pull the checks forward into design and code review where they are cheap. Do that and accessibility stops being a stressful scramble and becomes a marker of quality that benefits every user you have.
Frequently asked questions
What is web accessibility and what does WCAG require?
Web accessibility means building digital products so that people with disabilities can perceive, operate and understand them, and WCAG is the standard that defines what that requires in concrete terms. WCAG organizes its requirements around four principles, perceivable, operable, understandable and robust, and each specific rule ladders up to one of them. The current version, WCAG 2.2, adds criteria around focus visibility, target size and accessible authentication. Meeting these guidelines makes a product usable with assistive technologies like screen readers and keyboard-only navigation.
Which WCAG conformance level should a product team target?
Almost every product team should target WCAG Level AA as its practical standard. Level A covers only the most basic barriers and is not sufficient on its own, while Level AAA is the strictest and is not realistic to meet across an entire site. Level AA covers the criteria that matter most in everyday use and is the level that most laws and procurement policies reference. The sensible approach is AA across the whole product, with AAA reserved for individual high-value flows where it genuinely improves the experience.
What are the most common accessibility mistakes?
The most common accessibility failures are surprisingly consistent across products. They include using non-semantic markup like clickable divs instead of real buttons, missing labels on form inputs, insufficient colour contrast, and images without appropriate alt text. Keyboard traps and invisible focus indicators are also frequent, along with icon-only controls that have no accessible name. Because a short list of issues accounts for most audit findings, fixing these gets a team most of the way toward conformance.
How do I build accessibility into my team's workflow?
Accessibility sticks when it is part of how you build rather than a phase at the end. Add automated checks to your CI pipeline to catch a meaningful share of issues on every build, but pair them with manual keyboard testing and screen-reader spot checks, since automation finds only about a third of real problems. Catch contrast and target-size issues at the design stage before any code exists, and make accessibility part of your definition of done. Building it in from the start is far cheaper than retrofitting after launch.
What is new in WCAG 2.2?
WCAG 2.2 builds on 2.1 with a handful of new success criteria aimed mostly at people with motor and cognitive differences. Focus Not Obscured requires that keyboard focus is never hidden behind sticky headers or overlays, and Focus Appearance requires a focus indicator large and contrasting enough to see. Target Size sets a comfortable minimum for interactive controls, Dragging Movements requires a single-pointer alternative to any drag action, and Accessible Authentication removes cognitive-test barriers from login. Building these into shared components once means every screen inherits them.
Does accessibility help with SEO?
Yes, accessibility and SEO overlap significantly because both reward clean, semantic, well-structured markup. Proper headings, descriptive link text, alt attributes on images and logical document structure help screen readers and search engine crawlers understand your content in much the same way. Clear labels and predictable navigation also improve usability, which supports engagement signals that matter for search. Accessible sites tend to be better-built sites overall, so the investment pays back across both audiences and search visibility.
Is meeting WCAG a legal requirement?
Many markets reference WCAG in their accessibility laws and public-sector procurement rules, and Level AA is the level those references most often point to, which is a strong practical reason to treat AA as your target. That said, the specifics vary by country, sector and the nature of your product, so this should be read as general guidance rather than legal advice. Confirm your exact obligations with a qualified professional for your market, and treat WCAG conformance as the engineering foundation that makes meeting them straightforward.