WCAG 2.1 is the current stable version of the Web Content Accessibility Guidelines that most legal and regulatory frameworks reference. It extended WCAG 2.0 with 17 new success criteria — primarily addressing mobile interaction, low vision users, and cognitive accessibility — while keeping the original 2.0 criteria unchanged.
This article covers what changed, what the new criteria require technically, and what Level AA conformance means for a working frontend developer.
The Structure of WCAG
WCAG is organized around four principles — content must be Perceivable, Operable, Understandable, and Robust (POUR). Under each principle are guidelines; under each guideline are success criteria. Each criterion has a conformance level: A (minimum), AA (standard), or AAA (enhanced).
WCAG 2.1 adds 17 new success criteria to those inherited from 2.0. It does not modify or deprecate any 2.0 criterion. A site conforming to WCAG 2.1 AA automatically conforms to WCAG 2.0 AA.
WCAG 2.2 was published in October 2023. The relationship between 2.1 and 2.2 is covered in the WCAG 2.2 guide. This article focuses on 2.1 criteria specifically — what they introduced, and what they require.
The 17 New Success Criteria in 2.1
Perceivable
1.3.4 Orientation (AA) Content must not restrict its view to a single display orientation (portrait or landscape) unless that orientation is essential. An application that forces portrait-only mode on a device mounted in landscape orientation fails this criterion.
Implementation: avoid CSS or JavaScript that locks orientation. If a specific orientation is genuinely required (a piano keyboard tool that only works in landscape), that qualifies as essential. The threshold for “essential” is high.
1.3.5 Identify Input Purpose (AA) Input fields that collect personal data (name, email, address, phone, credit card) must expose their purpose so that browsers and assistive technologies can provide appropriate autofill behavior or iconography.
Implementation: use the HTML autocomplete attribute with the correct token for each field:
<input type="text" name="fname" autocomplete="given-name">
<input type="email" name="email" autocomplete="email">
<input type="tel" name="phone" autocomplete="tel">
The WCAG input purposes list defines the full set of recognized tokens. This criterion benefits users with cognitive disabilities who rely on autofill to avoid retyping, and users with motor disabilities who find form entry expensive.
1.3.6 Identify Purpose (AAA) Icons, regions, and UI components must expose their purpose through semantics so assistive technologies can present or adapt them. This AAA criterion extends 1.3.5 beyond form inputs to any UI component with a meaningful function.
1.4.10 Reflow (AA) Content must reflow to a single column at 320 CSS pixels wide without requiring horizontal scrolling. This accommodates users who zoom to 400% on a 1280px-wide browser — at that zoom level, the effective viewport is 320 CSS pixels.
Implementation: responsive layouts that genuinely work at narrow viewports satisfy this. Fixed-width containers, horizontal scroll regions, and two-dimensional scrolling layouts typically fail. Data tables are explicitly excepted where horizontal scrolling is essential.
1.4.11 Non-text Contrast (AA) UI components (form controls, focus indicators, icons) and informational graphics must have a contrast ratio of at least 3:1 against adjacent colors. This is distinct from 1.4.3 (Contrast Minimum), which applies to text.
A checkbox border against a white background must meet 3:1. A line chart’s data lines against the chart background must meet 3:1. Icons that are the sole means of conveying information must meet 3:1.
Focus indicators are specifically included. A focus ring that relies solely on a 1px border that doesn’t meet 3:1 fails this criterion.
1.4.12 Text Spacing (AA) Users must be able to apply the following text spacing adjustments without loss of content or functionality:
- Line height to at least 1.5× the font size
- Letter spacing to at least 0.12× the font size
- Word spacing to at least 0.16× the font size
- Spacing after paragraphs to at least 2× the font size
These are the values a user might set via a browser extension or user stylesheet. If applying them causes text to overflow containers and become unreadable, the implementation fails.
Implementation: avoid fixed-height containers for text content. Use min-height rather than height. Let text containers expand. The test is: apply the spacing values via a bookmarklet or browser override and confirm nothing breaks.
1.4.13 Content on Hover or Focus (AA) Content that appears on hover or keyboard focus (tooltips, popups, dropdowns) must meet three conditions:
- Dismissable — users can dismiss the appearing content without moving the pointer or focus (typically via Escape)
- Hoverable — users can move the pointer over the appearing content without it disappearing
- Persistent — the content stays visible until the user dismisses it, moves focus, or the information is no longer relevant
This primarily addresses tooltip implementations where moving the cursor over the tooltip itself would hide it — a common failure pattern.
Operable
2.1.4 Character Key Shortcuts (A) If a keyboard shortcut is implemented using a single character (letter, number, punctuation, or symbol), the user must be able to turn it off, remap it to a multi-key shortcut, or configure it to only activate when a component has focus.
Single-character shortcuts conflict with speech input software, where speaking a letter triggers the shortcut rather than dictating the character. This criterion protects speech-input users.
2.5.1 Pointer Gestures (A) All functionality that uses multi-point or path-based gestures (pinch-to-zoom, two-finger scroll, swipe) must be achievable through a single-pointer mechanism without a path-based gesture.
A map that requires pinch-to-zoom must also provide zoom buttons operable with a single tap or click. A carousel that requires swipe gestures must also provide previous/next buttons.
2.5.2 Pointer Cancellation (A) For single-pointer activation, at least one of the following must be true:
- No down-event: the function is not triggered on the down-event (mousedown, touchstart)
- Abort or undo: completion of the action can be aborted or undone
- Up-reversal: the up-event reverses any action taken on the down-event
- Essential: triggering on the down-event is essential
The practical guidance for most UI: fire actions on the up-event (mouseup, click, touchend), not the down-event. This allows users to cancel by moving away before release.
2.5.3 Label in Name (A)
For UI components that have a visible text label, the accessible name must contain that text. A button that shows “Search” visually but has aria-label="Go" fails — the accessible name doesn’t contain the visible label “Search”.
Speech recognition users activate controls by speaking the visible text. If the accessible name doesn’t match, activation fails.
Implementation: aria-label should start with or contain the visible text when both exist. Better still: when a visible label is present, use it as the accessible name and don’t override with aria-label.
2.5.4 Motion Actuation (A) Functionality triggered by device motion (shake, tilt, gyroscope) must be achievable through a UI component, and users must be able to disable the motion response.
An undo gesture triggered by shaking the device must also be accessible via a button.
Understandable
3.3.4 Error Prevention (Legal, Financial, Data) (AA) Already in WCAG 2.0. Not a 2.1 addition — included here for completeness since it’s often confused with new criteria.
Robust
4.1.3 Status Messages (AA) Status messages (success notices, error summaries, loading indicators, item counts) must be programmatically determinable through role or property so assistive technologies can present them to users without the message receiving focus.
If a form submission shows a success banner at the top of the page, that banner needs role="status" (for advisory messages) or role="alert" (for important, time-sensitive messages) so screen readers announce it without the user having to discover it through navigation.
<!-- Advisory status (polite announcement) -->
<div role="status">3 results found.</div>
<!-- Alert (assertive announcement) -->
<div role="alert">Your session will expire in 2 minutes.</div>
The distinction matters: role="alert" interrupts the current screen reader output, while role="status" waits for a natural pause. Use alert sparingly — only when the message is genuinely time-sensitive or critical.
The Mobile and Low Vision Focus
WCAG 2.1’s additions cluster around three areas:
Mobile interaction — 2.5.1 (Pointer Gestures), 2.5.2 (Pointer Cancellation), 2.5.3 (Label in Name), 2.5.4 (Motion Actuation) address touch interfaces and the ways mobile interaction patterns exclude users with motor, cognitive, or sensory disabilities.
Low vision — 1.4.10 (Reflow), 1.4.11 (Non-text Contrast), 1.4.12 (Text Spacing), 1.4.13 (Content on Hover or Focus) address users who zoom significantly or use screen magnification software.
Cognitive accessibility — 1.3.5 (Identify Input Purpose) and 2.1.4 (Character Key Shortcuts) benefit users with cognitive disabilities or who use input adaptations.
Level A vs Level AA
Level A criteria address failures that make content completely inaccessible to specific user groups. Level AA addresses failures that cause significant barriers. Level AAA criteria represent enhanced accessibility, often difficult or impossible to achieve across all content types.
For WCAG 2.1:
- New Level A criteria (minimum): 2.1.4, 2.5.1, 2.5.2, 2.5.3, 2.5.4
- New Level AA criteria (standard target): 1.3.4, 1.3.5, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 4.1.3
- New Level AAA criteria: 1.3.6, 2.5.5, 2.5.6
Most legal accessibility requirements reference Level AA conformance, which includes all Level A criteria.
WCAG 2.1 AA: A Practical Conformance Checklist
The following are the WCAG 2.1 AA criteria most commonly failed in practice:
Non-text contrast (1.4.11): Test form control borders, focus indicators, and icons against their backgrounds. The 3:1 ratio is lower than the 4.5:1 required for text, but form borders and focus rings frequently fail even this lower bar.
Text spacing (1.4.12): Apply the bookmarklet test. Fixed-height containers for body text and narrow sidebars are common failure points.
Reflow (1.4.10): Test at 320px viewport width (or zoom to 400% on a 1280px display). Horizontal-scroll failures are easy to introduce with data-dense UIs.
Status messages (4.1.3): Audit every asynchronous notification — form success/error messages, loading states, cart counts, search result counts — and verify they have appropriate ARIA live region roles.
Content on hover or focus (1.4.13): Test all tooltips and hover-revealed content for the three requirements: dismissable via Escape, hoverable without disappearing, persistent until dismissed.
Orientation (1.3.4): Check CSS for locked orientation declarations. Check JavaScript for orientation lock API calls.
Label in name (2.5.3): Audit all controls with visible labels and aria-label or aria-labelledby overrides. Ensure the accessible name contains the visible text.
Relationship to WCAG 2.2
WCAG 2.2 (published October 2023) removed one 2.1 criterion (4.1.1 Parsing, deprecated) and added 9 new criteria. It is backward compatible with 2.1 AA in all other respects.
The WCAG 2.2 guide on this site covers what changed between 2.1 and 2.2 specifically.
WCAG 2.1’s 17 additions are concrete and testable. Most of the AA-level criteria are verifiable through browser tooling, zoom testing, and assistive technology review without requiring specialized equipment. The mobile-interaction criteria (2.5.x) in particular reflect interaction patterns that have become standard since WCAG 2.0 was published in 2008 — they address real failure modes in modern interfaces that the original spec had no mechanism to address.
