There is a moment in every accessibility review when the conversation stops being abstract. It is when the STQC reviewer puts on headphones, opens NVDA, lands on the "Submit" button, and the announcement comes back as "graphic clickable." Not "Submit application". Not "Send". Just "graphic clickable" — what a screen reader says when nothing has been labelled. The button worked yesterday in QA. It will fail today, in the audit. The PDF gets stamped Non-compliant, and the development team goes back to the drawing board for the third time this quarter.
This is what WCAG 2.2 is for. It is the document that decides what counts as working.
The standard became a W3C Recommendation on 5 October 2023, with the addendum of 12 December 2024 confirming that 2.4.11 Focus Not Obscured is the version everyone now tests to. Eighty-six success criteria sit inside it: thirty-one at Level A, twenty-four at Level AA, thirty-one at Level AAA. Nine criteria are new since 2.1. One is gone — 4.1.1 Parsing, retired because modern browsers and tagged HTML have made it irrelevant. The Indian regulatory machinery — GIGW 3.0, IS 17802 for the SEBI mandate, the RPWD Act in its enforced form — now leans on the 2.2 set in practice if not always in formal citation.
Below is the checklist we run inside our lab. It is not the W3C's prose. It is what we test, in the order we test it, with the failure patterns we see most often. If you are an in-house compliance lead, you should be able to take it to your engineering team this afternoon.
What's in this piece
- 01The nine new criteria in 2.2 — ranked by what will actually fail you
- 02Level A — the floor (31 criteria)
- 03Level AA — the working standard (24 criteria)
- 04Level AAA — when, and when not
- 05How to actually test this checklist
- 06Mapping to GIGW 3.0, IS 17802, and the SEBI circular
- 07The order we run it in
- 08Questions reviewers actually ask
01 · The nine new criteria — ranked by what will fail you
Not all nine new criteria deserve equal attention. Two are landmines that will almost certainly fail every Indian banking, fintech and government site on first audit. Three more will catch most mobile-first products. The rest are either edge cases or near-impossible to fail if you have done the basics. Here they are in our order of audit priority.
The one your CISO needs to read first
A cognitive function test — remembering, transcribing, solving a puzzle — cannot be the only way for a user to authenticate, unless there is an alternative or the test itself is recognising the user's own object or biometric. In practice this means: image CAPTCHAs that ask the user to type distorted text fail this criterion outright. So does the "type the OTP from your SMS within 30 seconds" pattern when there is no paste-from-clipboard support. So does the "select all squares with traffic lights" challenge unless an audio alternative is offered.
The sticky-header silent killer
When a user tabs through a page, the focused element must not be entirely hidden by author-created content — most commonly a sticky header, a cookie banner, a chat widget, or a promotional sticky footer. Partial obscuring is permitted. Total obscuring is not.
This one is brutal because it almost never shows up in design QA. Designers test with mouse. The failure only appears when you tab from the navigation into a form field that scrolls into view behind the sticky header. We see it on roughly seven out of ten sites we audit.
The 24-by-24 rule
Pointer targets must be at least 24 by 24 CSS pixels, with exceptions for inline text links, equivalent controls available elsewhere on the page, user-agent defaults, and elements where the size is essential. The criterion also accepts targets smaller than 24px if there is at least 24 CSS pixels of spacing around them — the "spacing exception" most engineers miss.
Stop asking for the same data twice
Information the user has already provided in the same flow must either be auto-populated or be available for the user to select, unless re-entering is essential, required by security, or the previous information is no longer valid. Two-step forms that ask for the user's email on step one and then ask for it again on step three fail this. Confirm-email-address fields are explicitly exempted — they count as essential re-entry.
Always offer a single-pointer alternative
If a function uses a dragging movement — a slider, a kanban card, a signature pad, a file-reorder list — there must be a single-pointer alternative that does not require drag. Up and down arrows next to a reorderable list satisfy this. A slider that responds to keyboard arrow keys satisfies this. A signature pad that requires drawing with a finger fails it unless there is a typed-name alternative.
If help is offered, offer it in the same place
When help mechanisms — contact details, a help link, a chatbot, a self-service FAQ link — appear on multiple pages, they must appear in the same relative order. A chat icon that floats bottom-right on the homepage and bottom-left on the contact page is a fail. So is a help link that lives in the header on most pages but moves to the footer on checkout.
The stricter sibling of 2.4.11
Same rule, no partial-obscuring exception. The focused control must be entirely visible. We rarely test for this in commercial audits unless a client has set AAA as an internal target, which is uncommon.
The 2-pixel rule for keyboard focus
The focus indicator must have an area of at least the size of a 2-pixel-thick perimeter around the focused control, and a contrast ratio of at least 3:1 against adjacent colours. Default browser focus rings pass; many CSS-overridden focus styles do not. This is AAA, so optional in most regulatory contexts — but it is one of the cheapest AAA wins to take if you want a higher conformance claim.
The version with no exceptions for object recognition
Same as 3.3.8 but without the exception that allows recognising the user's own object or biometric. WebAuthn and passkeys satisfy this. Most everything else does not. Treat as AAA-aspirational.
The audit lab's blunt take
If you are scoping remediation for an enterprise site under regulatory deadline pressure, fix 3.3.8, 2.4.11, 2.5.8, 3.3.7 and 2.5.7 first. Together they account for almost every WCAG 2.2-specific failure we have flagged on Indian sites in the last year. The remaining four are either AAA — optional — or rare enough that you will discover them only in deep audit.
02 · Level A — the floor
Level A is the regulatory minimum. A site failing here is not a candidate for a defensible compliance claim. Most commercial sites pass the majority of Level A on first audit, with predictable exceptions around media, keyboard reachability, and form labelling. The table below lists all thirty-one Level A criteria with the failure pattern we see most often.
| SC | Title | What auditors check | Lvl |
|---|---|---|---|
| 1.1.1 | Non-text Content | Every image, icon, control has a text alternative. Decorative images marked as such. Form controls labelled. | A |
| 1.2.1 | Audio-only / Video-only (Prerecorded) | Transcript for audio-only; transcript or audio description for silent video. | A |
| 1.2.2 | Captions (Prerecorded) | Closed captions on all recorded video with audio. Auto-captions only acceptable if reviewed for accuracy. | A |
| 1.2.3 | Audio Description or Media Alternative | For prerecorded video, either audio description of visual content or a full text transcript. | A |
| 1.3.1 | Info and Relationships | Semantic HTML. Headings are real headings. Lists are real lists. Tables have th, scope, caption. | A |
| 1.3.2 | Meaningful Sequence | DOM order matches visual order. CSS positioning doesn't break reading flow. | A |
| 1.3.3 | Sensory Characteristics | Instructions don't rely solely on shape, colour, position, or sound. "Click the red button" needs the label too. | A |
| 1.4.1 | Use of Color | Information not conveyed by colour alone. Required form fields not marked only in red. | A |
| 1.4.2 | Audio Control | Auto-playing audio over 3 seconds has pause, mute, or volume control. | A |
| 2.1.1 | Keyboard | Every interaction works with keyboard alone. Custom widgets respond to Enter, Space, arrows as expected. | A |
| 2.1.2 | No Keyboard Trap | Focus can leave any component using only keyboard. Modal dialogs return focus correctly on close. | A |
| 2.1.4 | Character Key Shortcuts | Single-key shortcuts can be turned off, remapped, or only active when the control has focus. | A |
| 2.2.1 | Timing Adjustable | Time limits can be turned off, adjusted, or extended. Session timeout warnings with extend option. | A |
| 2.2.2 | Pause, Stop, Hide | Moving, blinking, scrolling content over 5s can be paused. Carousels need a pause control. | A |
| 2.3.1 | Three Flashes or Below Threshold | Nothing flashes more than three times per second in a way that could trigger seizures. | A |
| 2.4.1 | Bypass Blocks | Skip-to-main-content link, or proper landmark structure, lets keyboard users skip nav. | A |
| 2.4.2 | Page Titled | Every page has a unique, descriptive <title>. | A |
| 2.4.3 | Focus Order | Tab order matches visual reading order. No surprising jumps. | A |
| 2.4.4 | Link Purpose (In Context) | Link text plus its immediate context tells the user where it leads. "Click here" needs surrounding context. | A |
| 2.5.1 | Pointer Gestures | Multi-finger or path-based gestures have a single-pointer alternative. | A |
| 2.5.2 | Pointer Cancellation | Down-event doesn't trigger action; user can move away before up-event to cancel. | A |
| 2.5.3 | Label in Name | The accessible name of a control contains its visible label text. "Submit" button's aria-label can't say "send". | A |
| 2.5.4 | Motion Actuation | Shake-to-undo and similar device-motion features have a button alternative and can be disabled. | A |
| 3.1.1 | Language of Page | <html lang="en"> (or "hi", "ta", etc.) declared. Bilingual sites must mark language switches. | A |
| 3.2.1 | On Focus | Receiving focus doesn't trigger a context change — no auto-submit, no popup, no redirect. | A |
| 3.2.2 | On Input | Changing a form value doesn't auto-submit or redirect unless the user was warned. | A |
| 3.2.6 | Consistent Help NEW | Help mechanisms in the same relative order across pages that include them. | A |
| 3.3.1 | Error Identification | Errors are described in text. Not just a red border. | A |
| 3.3.2 | Labels or Instructions | Form fields have visible labels or instructions. Placeholders alone do not count. | A |
| 3.3.7 | Redundant Entry NEW | Don't ask the user for the same information twice in one flow. | A |
| 4.1.2 | Name, Role, Value | Every custom control exposes a name, role, and value to assistive tech. The hardest one to pass cleanly. | A |
The criterion that fails most often at Level A, by some distance, is 4.1.2 Name, Role, Value. It is also the one developers underestimate. Every custom dropdown, every modal, every tab list, every "looks like a button but is actually a styled div" — each must expose its name, role and current value to the accessibility tree. A site can ship 100 features with native HTML elements and pass 4.1.2 effortlessly. Replace one of them with a div+JavaScript composite and the criterion is at risk.
03 · Level AA — the working standard
This is what your auditor is testing to. GIGW 3.0, IS 17802, SEBI, EN 301 549, Section 508 refresh — all of them converge on Level AA as the working standard. The criteria below are additional to Level A.
| SC | Title | What auditors check | Lvl |
|---|---|---|---|
| 1.2.4 | Captions (Live) | Live broadcasts have real-time captions. Webinars, town halls. | AA |
| 1.2.5 | Audio Description (Prerecorded) | Prerecorded video has audio description for visual-only information. | AA |
| 1.3.4 | Orientation | Content works in both portrait and landscape unless one is essential. | AA |
| 1.3.5 | Identify Input Purpose | Form fields collecting personal data use HTML autocomplete tokens (email, tel, given-name). | AA |
| 1.4.3 | Contrast (Minimum) | 4.5:1 for body text, 3:1 for large text (18pt+ or 14pt+ bold). | AA |
| 1.4.4 | Resize Text | Text can be zoomed to 200% without loss of content or function. | AA |
| 1.4.5 | Images of Text | Use real text unless the image carries information no text can. Bilingual government PDFs frequently fail this. | AA |
| 1.4.10 | Reflow | Content reflows at 320 CSS pixels wide without horizontal scrolling, except for data tables and complex visuals. | AA |
| 1.4.11 | Non-text Contrast | 3:1 contrast for UI components and graphical objects required to understand content. | AA |
| 1.4.12 | Text Spacing | Content remains readable when line height, letter spacing, word spacing, paragraph spacing are increased. | AA |
| 1.4.13 | Content on Hover or Focus | Tooltips can be dismissed, hovered, and persist until dismissed. The most-failed AA criterion in the last two years. | AA |
| 2.4.5 | Multiple Ways | At least two ways to find a page — nav, search, sitemap, related links. | AA |
| 2.4.6 | Headings and Labels | Headings and form labels describe their topic or purpose meaningfully. | AA |
| 2.4.7 | Focus Visible | A visible focus indicator on every keyboard-focused control. Browser default counts; "outline: none" without replacement fails. | AA |
| 2.4.11 | Focus Not Obscured (Min) NEW | Focused element not entirely hidden by sticky content. | AA |
| 2.5.7 | Dragging Movements NEW | Drag functions have a single-pointer alternative. | AA |
| 2.5.8 | Target Size (Minimum) NEW | Pointer targets at least 24×24 CSS pixels, or sufficiently spaced. | AA |
| 3.1.2 | Language of Parts | Inline language changes marked with lang attribute. Critical for Hindi-in-English government text. | AA |
| 3.2.3 | Consistent Navigation | Repeated navigation in the same relative order on each page. | AA |
| 3.2.4 | Consistent Identification | Components with the same function identified consistently across the site. | AA |
| 3.3.3 | Error Suggestion | When an error is detected and a fix is known, suggest it. "Email must include @" not just "invalid". | AA |
| 3.3.4 | Error Prevention (Legal, Financial, Data) | Submissions can be reversed, checked, or confirmed. Payment flows almost always need this. | AA |
| 3.3.8 | Accessible Authentication (Min) NEW | No cognitive-test-only authentication. Paste, autofill, and alternatives must be available. | AA |
| 4.1.3 | Status Messages | Dynamic status changes (form errors, cart updates, search counts) announced via ARIA live regions. | AA |
The criterion that surprises clients most is 1.4.13 Content on Hover or Focus. Tooltips that disappear when the cursor moves away to read them, that cannot be dismissed with Esc, that don't persist long enough to be useful — these fail. The pattern is so common in design systems that we now include it as a default in our scoping conversation.
04 · Level AAA — when, and when not
Level AAA is rarely the right target. The W3C itself states that "it is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content." We agree. Aspiring to AAA across a site usually means failing transparency to demand the impossible.
There are three contexts where AAA makes sense. The first is single-feature scope — a sign language interpretation for a critical announcement video. The second is brand or regulatory differentiation — declaring AAA conformance for a specific page or flow to signal commitment. The third is internal — when a product is itself an accessibility tool, conformance at the highest available level is table stakes.
The 31 Level AAA criteria add: 7:1 contrast (1.4.6), sign language for video (1.2.6), extended audio description (1.2.7), no time limits (2.2.3), three flashes (2.3.2), location indicators (2.4.8), link purpose without context (2.4.9), section headings (2.4.10), focus appearance precision (2.4.13), reading level limits (3.1.5), unusual word definitions (3.1.3), and the enhanced versions of focus-not-obscured and accessible authentication. Few sites need all of them; most can claim a handful with little effort.
05 · How to actually test this checklist
Three groups of tools, three layers of testing. Each layer catches a different class of failure. None of them alone is enough.
Automated scanners — the 30 percent floor
Axe, Lighthouse, WAVE, Pa11y, the open-source Accessibility Insights, and our own scanner at web.accesssure.in all do roughly the same job: parse the DOM, run a rule engine, return a list of issues. They catch contrast failures, missing labels, empty links, duplicated IDs, missing language attributes, ARIA misuse. They cannot judge whether alt text is meaningful, whether focus order is sensible, whether a button's name reflects its action. Internal industry estimates put automated coverage at 30 to 40 percent of WCAG 2.2 criteria. Our own breakdown, audited against a control set of 200 known violations across 14 templates, came in at 32 percent. Treat the scanner output as a floor, not a result.
Manual keyboard and screen reader testing — the 70 percent
This is where the real audit happens. Tab through the entire page, top to bottom. Use Shift+Tab to go back. Use arrow keys inside menus and radio groups. Open NVDA on Windows, VoiceOver on macOS, TalkBack on Android. Listen. Most failures of 1.3.1, 2.4.3, 2.4.11, 4.1.2 and 4.1.3 only surface when you hear the announcement. Auditors who only "read the code" miss roughly half of what an audit must find.
Cognitive and content review — the part most teams skip
Reading levels. Plain language. Sensible link text. Meaningful headings. These do not yield to tooling. They require an editor with accessibility literacy. A document at 14th-grade reading level on a citizen-services portal is technically WCAG-compliant and practically inaccessible. AAA criterion 3.1.5 makes this explicit; most A and AA audits stop short of it, but they shouldn't.
06 · Mapping to GIGW 3.0, IS 17802, and the SEBI circular
WCAG 2.2 does not exist in isolation in India. Three documents do most of the regulatory lifting, and each cites WCAG slightly differently.
GIGW 3.0 (Guidelines for Indian Government Websites, 2024 edition)
GIGW 3.0 is the operational standard for Central and State government websites and PSU portals, issued by MeitY through NIC. It requires WCAG 2.1 Level AA at minimum, with several specific additions: bilingual content support, page-load performance floors, security baselines, and content-management transparency. STQC's Certificate of Quality Website (CQW) is awarded on the basis of a GIGW 3.0 audit conducted by an STQC SAB SETL-1 empanelled laboratory — ITQCR is one of the few in India authorised to issue them. In practice, GIGW reviewers are already applying WCAG 2.2's focus-and-target criteria during evaluation. Plan for 2.2 even though the formal text cites 2.1.
IS 17802 (Indian Standard for ICT Accessibility, 2020)
IS 17802 Part 1 covers ICT products and services; Part 2 covers web content. It is functionally aligned with EN 301 549, which itself adopts WCAG by reference. The SEBI circular of August 2023 requires regulated entities — listed companies, mutual funds, stockbrokers — to make their websites and apps IS 17802-compliant. In audit terms this means WCAG 2.1 AA as the testable floor, with reviewers expecting 2.2-level remediation by 2026 audit cycles.
RPWD Act 2016, accessibility rules 2017
The Rights of Persons with Disabilities Act and its accessibility rules establish the legal mandate for ICT accessibility across the public sector and any private entity providing services to the public. The Act references "international standards" without naming WCAG directly; the operative interpretation by NCPEDP and the Department of Empowerment of Persons with Disabilities is WCAG 2.1 AA at minimum, with movement towards 2.2 in current advisory guidance.
The pragmatic answer for Indian compliance teams
Test to WCAG 2.2 AA. Report against WCAG 2.1 AA where the contract specifies it. The 2.2 additions are nine in number; most are inexpensive to remediate; all of them are visible in current STQC review behaviour. There is no scenario in which preparing for 2.2 hurts a compliance position.
07 · The order we run it in
Inside the lab, an audit is not a top-to-bottom sweep of the checklist. It is a sequence chosen to surface the highest-impact failures first, on the smallest representative scope, before committing the full team to deep review. The order matters because it changes how findings land with engineering teams.
- Automated scan across the representative URL set. Catches the floor — labels, contrast, language attribute, duplicate IDs. Output goes into the evidence bundle without being treated as the audit.
- Keyboard-only walkthrough on the primary user journey. Login, search, checkout, application submission, whichever applies. Catches 2.1.x, 2.4.3, 2.4.7, 2.4.11.
- NVDA + JAWS pass on the same journey. Surfaces 4.1.2 and 4.1.3 issues that nothing else will find. Two readers because they disagree often enough to matter.
- Forms and authentication deep-dive. Where 3.3.x and the new 3.3.7/3.3.8 fail.
- Mobile (real device) check. Target size (2.5.8), orientation (1.3.4), reflow (1.4.10), motion (2.5.4), gestures (2.5.1, 2.5.7).
- Document and media review. Captions, audio description, PDF accessibility for downloadable resources.
- Content review. Headings, link text, meaningful labels, plain language.
Roughly 70 percent of significant findings surface in steps 2–4. If a client is under budget pressure, those are the steps we protect. Steps 1 and 7 are cheap. Step 5 cannot be done remotely. Step 6 is non-negotiable for government work where the citizen download is often the primary content.
Run this checklist against your live site, free.
Our web accessibility scanner runs the automated layer of this checklist on any public URL and returns evidence-ready findings with NVDA simulation video. Use it as a starting point before scoping a full manual audit.
Scan a page free → Scope a full audit08 · Questions reviewers actually ask
Is WCAG 2.2 mandatory in India?
What is the difference between WCAG 2.1 and 2.2?
Which WCAG level should we target?
Can automated tools test the full WCAG 2.2 checklist?
How long does a WCAG 2.2 audit take?
What if our site uses an accessibility overlay widget?
Do you provide a downloadable copy of this checklist?
A checklist is not a compliance certificate. It is the question your auditor will ask. Knowing the questions in advance is most of the work.