WCAG 2.1 AA is a set of testable requirements that make web and app content more accessible across devices and abilities. It builds on WCAG 2.0 by adding criteria for mobile, low vision, and cognitive needs while keeping the same four principles: Perceivable, Operable, Understandable, and Robust. Conformance applies to complete pages and states, not isolated components.

Key AA criteria added in 2.1 include:

• Orientation (1.3.4): Do not lock content to portrait or landscape unless essential.
• Identify Input Purpose (1.3.5): Use programmatic semantics so browsers and assistive tech can understand the purpose of common fields (e.g., autocomplete for name, email).
• Reflow (1.4.10): Support single‑direction scrolling without loss of content at 320 CSS px width (small screens) or 256 CSS px height.
• Non‑Text Contrast (1.4.11): Provide at least 3:1 contrast for active UI components and meaningful graphics against adjacent colors.
• Text Spacing (1.4.12): No loss of content or function when users increase line, paragraph, letter, and word spacing within specified values.
• Content on Hover or Focus (1.4.13): Tooltips and flyouts must be dismissible, hoverable, and persist while users move the pointer or focus.
• Status Messages (4.1.3): Announce non‑modal updates programmatically so assistive technologies convey success, error, or progress without moving focus.

These build on core AA expectations already familiar to teams: sufficient text color contrast, keyboard operation, visible focus, accessible forms and errors, adaptable layouts, meaningful structure, and compatibility with assistive technologies.

A practical path to 2.1 AA looks like a repeatable delivery process, not a one‑time fix. Use this approach to make steady, verifiable progress:

• Scope by pages and states: Inventory complete templates and key user flows. WCAG conformance is measured on full pages, including dynamic states like modals and validation errors.
• Adopt a living checklist: Use the WCAG 2.1 AA Quick Reference as a canonical checklist, mapped to your components and patterns.
• Design system first: Bake AA into tokens and components (colors, focus indicators, spacing, inputs, alerts). This prevents rework and speeds adoption.
• Test like users do: Combine automated tests with manual keyboard review, screen reader checks, zoom/reflow at 400%, and pointer/hover behavior.
• Document programmatic semantics: Ensure form fields, landmarks, and status messages expose roles, names, and states the way assistive tech expects.
• Fix, verify, and prevent regressions: Track defects by success criterion, write unit and end‑to‑end tests, and add accessibility checks to CI/CD.
• Train the team: Give designers, engineers, QA, and content authors role‑specific standards and examples.

Evidence that resonates with stakeholders:

• Issue counts and pass rates by criterion and by component.
• Before/after screenshots of reflow, focus, and color contrast changes.
• Short recordings of screen reader and keyboard flows to validate improvements.

Most accessibility issues cluster around a handful of patterns. Addressing these early removes friction for everyone:

• Low contrast UI and icons: Borders, placeholders, and icons often fail the 3:1 non‑text contrast requirement. Use tokens that guarantee contrast in all states.
• Invisible or inconsistent focus: Thin or low‑contrast outlines make keyboard navigation difficult. Provide a distinct, consistent focus style with a visible offset.
• Tooltip and popover behavior: Hover/focus content that disappears when the pointer moves to it, or that cannot be dismissed, violates 1.4.13. Make it dismissible and hoverable.
• Content that does not reflow: Fixed grids or absolute elements that trigger two‑direction scrolling fail 1.4.10. Use flexible layouts and test at 320 px width and zoom at 400%.
• Unannounced status changes: Success banners and inline errors that lack roles or ARIA relationships are silent to screen readers. Add appropriate roles and associate errors with inputs.
• Form field purpose: Omitting well‑supported autofill purposes blocks personalisation and assistive features. Mark up common inputs with correct attributes.

Tackle these patterns within your design system to uplift many screens at once and reduce long‑term cost.