Perceivable
Users must be able to sense the information — through sight, hearing or touch. If a screen reader cannot read an image, or a deaf user cannot access a podcast, your site is not perceivable to them.
Web accessibility
Skip to guide content
1.1.1
A
1.3.1
A
1.4.3
AA
1.4.10
AA
1.4.11
AA
2.1.1
A
2.4.4
A
2.4.7
AA
2.4.11
AA new
2.5.8
AA new
3.2.6
A new
3.3.2
A
3.3.7
A new
3.3.8
AA new
4.1.2
A
A complete guide to what web accessibility is, the criteria that break most websites, how the WCAGHub Web Checker detects 77 issues across two engines, and where WCAG 2.2 is legally enforceable. Written for developers, designers and compliance leads.
77
Automated Checks
Dual
Engine Scanning
6
New WCAG 2.2 Criteria
6
Legal Jurisdictions
What it is
Web accessibility, in plain language
Web accessibility means building websites and web applications that everyone can perceive, operate and understand — regardless of sight, hearing, mobility, cognition, age or the device they are using. It is not a feature for a small minority. Around one in six people worldwide live with a significant disability, and almost every user will experience a temporary or situational impairment at some point — a broken arm, bright sunlight, a noisy train carriage.
The technical reference is the Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C. WCAG is organised around four principles — perceivable, operable, understandable and robust — and breaks each principle down into 87 testable success criteria at three conformance levels: A (minimum), AA (the legal target in most jurisdictions) and AAA (enhanced).
Inaccessible websites exclude users, damage brand reputation, hurt SEO — and in Australia, the US, the EU, the UK and Canada, they expose you to legal complaints under the Disability Discrimination Act, ADA, European Accessibility Act, Equality Act and Accessible Canada Act respectively. The good news: most accessibility is about doing the HTML, CSS and JavaScript you already know, a little more carefully — and the WCAGHub Web Checker can find 77 distinct accessibility issues automatically so you know exactly what to fix.
The four principles
POUR: Perceivable, Operable, Understandable, Robust
Every WCAG success criterion falls under one of these four headings. Learn what each one means and you already understand the shape of the whole standard.
Operable
All functionality must work by keyboard alone and give the user enough time. Many disabled users never touch a mouse — if a feature needs hover, drag or precise clicks, it is not operable.
Understandable
Content and interface behaviour must be predictable. Declare the page language, label your form fields, explain errors, and never surprise the user with a layout that changes on focus or selection.
Robust
Code must be parseable by current and future assistive technology. That means valid HTML, correct ARIA where native semantics are insufficient, and status messages that get announced without taking focus.
Top 15 failures
The criteria that break most websites
WebAIM analyses the top one million home pages every year. These 15 success criteria account for the vast majority of detected failures — fix them and you eliminate most of your risk. All 15 are detected automatically by the WCAGHub Web Checker.
Non-text content (alt text)
Every meaningful image needs an alt attribute that conveys its purpose. Decorative images use alt="". Never leave alt missing — screen readers will read the file name instead.
Info and relationships
Structure must be conveyed in code, not only visually. Use <h1>–<h6> in order, <label for> on inputs, <th> with scope on data tables, and real lists with <ul>/<ol>.
Contrast (minimum)
Normal text needs a contrast ratio of at least 4.5:1 against its background, large text 3:1. Light grey on white is the single most common failure on the web.
Reflow
Content must reflow to a single column at 320 CSS pixels wide without horizontal scrolling or loss of information. Test by zooming the browser to 400 % on a 1280-pixel viewport.
Non-text contrast
Icons, form field borders, focus indicators and meaningful graphical elements need 3:1 contrast. A thin grey border on a white input almost always fails this criterion.
Keyboard
Every interactive element must be reachable and operable with keyboard alone. Custom components built on <div> need tabindex="0", keyboard event handlers, and an appropriate ARIA role.
Link purpose (in context)
Avoid “click here” and “read more” links repeated across a page. Screen-reader users pull up a list of links out of context — each one must make sense on its own.
Focus visible
The focused element must be clearly distinguishable. Never write outline: none without a replacement. Design a focus style that meets 3:1 non-text contrast — ideally a 2–3 px outline with offset.
Focus not obscured — new in WCAG 2.2
The focused element must not be fully hidden by sticky headers, cookie banners or modal overlays. Leave at least part of the focused element visible at all times.
Target size (minimum) — new in WCAG 2.2
Pointer targets must be at least 24×24 CSS pixels, with limited exemptions for inline text and default browser controls. Best practice is still 44×44.
Consistent help — new in WCAG 2.2
If your site offers help (contact details, FAQ link, live chat), it must appear in the same relative order on every page that includes it. Do not shuffle support links between pages.
Labels or instructions
Every form input needs a visible, programmatically associated label. Placeholder text is not a label — it disappears on focus and often fails contrast.
Redundant entry — new in WCAG 2.2
Information the user already entered in the same process must be auto-populated or available to select. No forcing the user to retype their email on the confirmation step.
Accessible authentication — new in WCAG 2.2
Authentication must not rely solely on a cognitive function test (remembering, transcribing, solving puzzles). Support password managers, passkeys or object-recognition alternatives.
Name, role, value
Every UI control must expose its accessible name, role and current state to assistive technology. Prefer native HTML (<button>, <select>); only reach for ARIA when native semantics are insufficient.
How WCAGHub finds them
Dual-engine scan. AI fixes. Screen reader score.
The Web Checker is not a single-pass validator — it runs 77 distinct checks across two engines, prioritises them with a smart scoring model, explains every issue in the idiom of your framework, and scores your site for three screen readers.
PHP Static Engine
39 checksParses raw HTML as served — no JavaScript required. Fast, deterministic, finds structural problems that render identically for every visitor: missing <title>, missing lang, unlabelled inputs, invalid ARIA references, table headers without scope, meta refresh traps and the new WCAG 2.2 criteria around help, redundant entry and authentication.
- Runs on any server, including CDN-cached HTML
- Detects 39 issues including all 6 new WCAG 2.2 criteria
- Framework detection: 19+ stacks (React, Vue, Angular, WP, etc.)
Puppeteer Rendered-DOM Engine
38 checksHeadless Chrome loads your page with real CSS, JavaScript and fonts — then we inspect what a user actually sees. Catches colour contrast against computed backgrounds, focus indicators, dynamic ARIA states, modal focus traps, autoplay, small touch targets, SVGs without names, and React/Vue/Angular components that only exist after hydration.
- Computed CSS contrast on every text node
- Progressive scroll catches lazy-loaded components
- Cloudflare & LiteSpeed stealth bypass built in
Fix with AI — framework-aware
LiveClick Fix with AI on any issue and the Web Checker generates a correction in the idiom of the stack we detected. A React app gets a JSX component. A Vue site gets a template. A WordPress theme gets a functions.php snippet with the right hook. Not generic vanilla HTML — code you can paste straight into your repo.
React / Next.js
Vue / Nuxt
Angular
Svelte / Kit
WordPress + Bricks
Shopify Liquid
Tailwind CSS
Bootstrap 5
Detecting 19+ frameworks and templating engines. If we recognise your stack, the fix lands in the right syntax on the first try.
Screen reader intelligence
0–100 score for every assistive tech
Every scan includes three independent scores weighted for the actual quirks of each screen reader — not just a shared WCAG tally.
NVDA (Windows)
Free, open source, the most-used screen reader in WebAIM surveys. Scored on landmark nav, form labels, live regions and heading structure.
JAWS (Windows)
The legacy enterprise standard. Penalises table complexity, nested ARIA, unexpected role overrides, and any aria-label on non-interactive elements.
VoiceOver (macOS & iOS)
Apple's built-in screen reader. Rewards semantic HTML, clean focus order and region landmarks; penalises interactive divs and custom controls without role + tabindex.
After the scan
Smart priorities and live preview
Smart Priorities
We rank every issue by legal risk (which WCAG level + jurisdiction), user impact (blocker vs. friction), and fix cost (one-line attr vs. structural rewrite). The first five items on your list are always the ones that move the needle most.
Live Preview with markers
Every issue is pinpointed on a full-page screenshot with clickable markers — red dots for errors, blue for warnings. Click a marker and you see the exact selector, the WCAG criterion, the AI fix, and screen-reader guidance in a side panel. Export to branded PDF whenever you like.
How to test
Three layers, one confident answer
No single method catches every problem. A good audit combines automated scanning, manual testing with assistive technology, and — where budget allows — session testing with real disabled users.
Automated scanning
~ 30–40 % coverageFast, consistent, repeatable. Catches missing alt, colour contrast, heading order, invalid ARIA, missing form labels and many structural issues — but cannot judge whether your alt text is meaningful or your link text makes sense.
- WCAGHub Web Checker (77 checks)
- axe DevTools, WAVE, Lighthouse
- CI integration (pa11y, axe-core)
Manual testing
Keyboard + SRNavigate every page and flow with the Tab key alone. Then run through with a screen reader — NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android — to expose what the DOM actually exposes.
- Tab / Shift-Tab / Enter / Space
- NVDA, JAWS, VoiceOver, TalkBack
- 400 % zoom reflow check
User testing
Real evidenceAutomation flags issues, but only disabled users tell you whether your product is actually usable. Recruit blind, motor-impaired and cognitively impaired testers through Fable, Applause, or local disability organisations.
- Task-based moderated sessions
- Mix of disability types
- Pay your participants
Legal frameworks
Where WCAG 2.2 is legally enforceable
The technical target is the same in every country; the law and the enforcement body change. The Web Checker maps every issue to your chosen jurisdiction and labels the report with the exact statute you need to cite.
AU
Australia
Disability Discrimination Act 1992
DDA + Digital Service Standard (DTA). Federal government requires WCAG 2.2 AA. Complaints handled by the Australian Human Rights Commission.
US
United States
ADA · Section 508 · 21st CVAA
DOJ Title II rule requires WCAG 2.1 AA for state and local government web content. Section 508 refresh references WCAG 2.0 AA.
EU
European Union
European Accessibility Act 2025
EAA applies to private-sector services from June 2025. EN 301 549 references WCAG 2.1 AA (migrating to 2.2) plus ICT-specific requirements.
UK
United Kingdom
Equality Act 2010 · PSBAR 2018
Public-sector bodies bound by the 2018 Regulations: WCAG 2.2 AA plus an accessibility statement. Private sector must make reasonable adjustments.
CA
Canada
ACA · AODA · LAPHO
Accessible Canada Act federal. Ontario AODA requires WCAG 2.0 AA, moving towards 2.1. Quebec LAPHO similar scope.
WW
Global baseline
WCAG 2.2 A + AA
W3C Recommendation, superset of every regional law. Meeting WCAG 2.2 AA clears most jurisdictional requirements simultaneously.