WCAG 2.2 AA Quick Reference and Component Checklist

What this is

A component-level checklist for Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, written for teams building and maintaining components in a content management system (CMS) rather than for auditors. It is the working bar we hold components to before they ship, and it is deliberately short enough to run on every component instead of once a year.

WCAG 2.2 is additive over 2.1: everything in 2.1 still applies, and 2.2 adds the criteria in the first section below. The Americans with Disabilities Act (ADA) Title II rule names WCAG 2.1 AA as the technical standard, with compliance dates of April 26, 2027 for public entities serving 50,000 or more people and April 26, 2028 for smaller entities. Building to 2.2 clears that bar with margin.

The WCAG 2.2 additions that hit components

• Focus not obscured. A focused element is never fully hidden behind sticky headers, cookie banners, or other fixed chrome. Use scroll margin and reserve space; verify with the keyboard.
• Dragging movements. Every drag interaction (sliders, carousels, reordering) has a single-pointer or keyboard alternative, usually a button.
• Target size (minimum). Interactive targets are at least 44 by 44 CSS pixels, with spacing between adjacent hit areas. Watch footer link farms and icon-only controls.
• Consistent help. Help and contact patterns stay in the same relative location across templates. Put them in shared chrome.
• Accessible authentication. Login does not require a cognitive test (like transcribing a code) with no accessible alternative such as a password manager or copy and paste.

Per-component checklist

Run this before a component merges. A component is done when every line is true or the exception is documented in the component folder.

Keyboard

• Every interactive element is reachable and operable by keyboard alone.
• Focus order matches visual order. No positive tabindex.
• A visible focus indicator is present on every focusable element (:focus-visible, tokenized, not removed globally).
• Modals and drawers trap focus while open and restore focus to the trigger on close.
• Focus never lands under fixed or sticky chrome.

Semantics and names

• Interactive elements use real semantic elements (<button>, <a>), not styled generics.
• Every control has an accessible name, including icon-only buttons and inputs.
• Headings are in order and describe the structure, not the styling.
• Images have alt text; informative images require it, decorative images use empty alt.

Reach and motion

• Touch targets are at least 44 by 44 CSS pixels with adequate spacing.
• Drag interactions have a non-drag alternative.
• Auto-advancing content (carousels) has a pause control and respects reduced-motion.

Content and contrast

• Text contrast meets AA against the design tokens, not a one-off hex value.
• Link text describes its destination. No "click here".
• Error messages are programmatically associated with their fields.

CMS enforcement (the durable part)

• The most likely author mistake for this component is prevented by a field constraint (required alt, max length, allowed link types, droplink instead of free text).
• Front-end accessibility that an author could override is instead enforced at the field, rendering-default, or render-time layer.

Tooling honesty

Automated scans (Axe, Lighthouse) are the floor of this checklist, not the ceiling. A Lighthouse accessibility score of 100 means the automated subset found nothing, not that the component meets AA. Keyboard flow, screen reader announcements, and whether the content makes sense are human checks that no scanner replaces. Overlay widgets do not make a site compliant. Use the scanners to keep a passing component from regressing, and use a keyboard and a screen reader to decide whether it passed in the first place.

Companion reading

This checklist is the component-level bar behind WCAG 2.2 vs 2.1 for Sitecore Teams and the review pass in AI-Generated UI Components Fail WCAG 2.2.