•
•
•
•
•
•
•
Understanding WCAG 2.2 success criteria, common accessibility failures, semantic HTML, ARIA, keyboard navigation, testing tools, and the legal landscape businesses now face.
Web accessibility is no longer a niche concern handled after launch — it is a legal requirement in a growing number of countries, and a genuine usability issue affecting a significant share of internet users with visual, motor, auditory, or cognitive disabilities. WCAG 2.2 (Web Content Accessibility Guidelines, version 2.2), published by the W3C, is the current global reference standard that most laws and procurement policies point to.
This guide covers what WCAG 2.2 actually requires, the accessibility failures that show up most often on real websites, how to fix them using semantic HTML and ARIA, the tools used to test compliance, and the legal landscape businesses now operate under.
WCAG 2.2 organizes accessibility requirements around four principles, often remembered by the acronym POUR:
Each guideline under these principles has specific, testable success criteria, rated at three conformance levels:
WCAG 2.2 added several new success criteria beyond WCAG 2.1, with particular emphasis on focus visibility, target size for touch and click interactions, and clearer requirements around authentication methods that don't rely solely on cognitive tests like memorizing passwords.
Automated and manual audits consistently surface the same handful of failures across most websites, regardless of industry:
alt="" that would let screen readers skip them.The single highest-leverage fix for most accessibility problems is using semantic HTML correctly before reaching for ARIA at all. Native HTML elements come with built-in accessibility behavior that custom-built components have to replicate manually.
<button> for anything clickable that performs an action, not a styled <div> with a click handler.<nav>, <main>, <header>, <footer>, and <section> to give the page structure that screen readers can navigate by landmark.<h1>–<h6>) in a logical order — screen reader users frequently navigate a page by jumping between headings.<label> elements properly associated with form inputs via the for/id attributes.<table> with <th> and appropriate scope attributes for genuinely tabular data, not for layout.The general rule: "No ARIA is better than bad ARIA." ARIA should fill gaps semantic HTML cannot cover, not replace it.
ARIA (Accessible Rich Internet Applications) attributes let developers describe custom components — tabs, modals, accordions, custom dropdowns — to assistive technology when native HTML has no equivalent element.
Common, correctly-scoped ARIA patterns:
aria-label or aria-labelledby to name an element when visible text alone isn't sufficient (e.g., an icon-only button).role="dialog" combined with proper focus management for modal windows.aria-expanded on elements that toggle visibility, such as accordions and dropdown menus.aria-live regions to announce dynamic content changes (like a form validation error or a loading status) to screen reader users without requiring a page refresh.Misused ARIA is a frequent cause of accessibility bugs — adding role="button" to a <div> without also handling keyboard events (Enter/Space) creates something that looks accessible to an automated scanner but isn't actually usable.
A genuinely accessible site must be fully operable using only a keyboard. Practical checks:
Effective accessibility testing combines automated scanning with manual review, since automated tools catch roughly a third of real accessibility issues — the rest require human judgment.
| Method | What it catches | Example tools |
|---|---|---|
| Automated scanners | Contrast ratios, missing alt text, missing labels, ARIA misuse | axe DevTools, WAVE, Lighthouse accessibility audit |
| Screen reader testing | Real navigation experience, announcement accuracy | NVDA, JAWS, VoiceOver |
| Keyboard-only testing | Tab order, focus traps, unreachable elements | Manual testing (unplug the mouse) |
| Manual/expert review | Context, cognitive load, real-world usability | Accessibility consultants, internal audits |
| User testing | Real-world barriers automated tools miss | Testing with people who use assistive technology |
Web accessibility has shifted from a best practice to a binding legal requirement in many major markets:
Accessibility overlay widgets — scripts marketed as an instant compliance fix — have consistently performed poorly in both usability testing and litigation outcomes, since they often fail to fix underlying structural issues and can even interfere with assistive technology.
Beyond legal exposure, accessibility failures exclude a meaningful share of potential users and customers, and case after case shows that accessibility fixes — better contrast, clearer labels, logical structure — tend to improve usability for everyone, not just users of assistive technology. Search engines and AI answer systems also increasingly favor well-structured, semantic content, meaning accessibility work overlaps directly with SEO and AEO gains.
Expect enforcement of the European Accessibility Act to intensify as more member states finalize penalty structures, and expect WCAG 2.2's newer criteria — particularly around focus visibility and target size — to become standard audit checkpoints. Automated testing is also improving through AI-assisted accessibility scanners, though manual and assistive-technology testing remains necessary to catch what automation misses.
Is WCAG 2.2 legally required everywhere?
No single global law mandates WCAG 2.2 specifically, but many national and regional laws (EAA, ADA-related rulings, Section 508) reference WCAG as the technical standard for compliance, typically at Level AA.
What's the difference between WCAG 2.1 and 2.2?
WCAG 2.2 adds new success criteria on top of 2.1, focused on areas like focus appearance, minimum target size for interactive elements, and accessible authentication methods.
Do accessibility overlay tools make a site compliant?
Generally no — overlays often fail to fix underlying code-level issues and have been repeatedly cited as inadequate in accessibility lawsuits and expert audits.
How much does it cost to make a website accessible?
It varies widely by site size and existing code quality, but starting with semantic HTML from the outset is far cheaper than retrofitting accessibility onto an existing, poorly structured site.
Can automated tools alone confirm compliance?
No — automated scanners catch a meaningful but limited subset of issues; manual review and testing with actual assistive technology are necessary for genuine compliance confidence.
WCAG 2.2 compliance is best approached as an ongoing engineering discipline, not a one-time audit. Prioritizing semantic HTML, correct and minimal ARIA usage, full keyboard operability, and a mix of automated and manual testing addresses the overwhelming majority of real-world accessibility failures — while also reducing legal exposure as accessibility regulations continue to tighten globally.