WCAG examples
WCAG 2.2 AA Examples
Learn WCAG 2.2 AA testing with practical pass/fail examples for product teams, QA testers, and developers.
What WCAG 2.2 AA Covers
WCAG 2.2 AA is a practical accessibility target used by many teams. It is organized around perceivable, operable, understandable, and robust experiences. Automated checks help find many issues, but manual keyboard, screen reader, zoom, and workflow testing is still required.
- Perceivable: text alternatives, headings, color contrast, captions, labels, and meaningful structure are available to more than one sense.
- Operable: every action works with keyboard, pointer, touch, and assistive technology without traps or hidden focus.
- Understandable: instructions, labels, errors, navigation, and repeated components behave consistently.
- Robust: semantic HTML and carefully chosen ARIA expose reliable names, roles, states, and relationships.
- WCAG 2.2 adds practical focus, target size, dragging, and consistent help requirements that affect modern SaaS interfaces.
Official references
Forms, Buttons, Links, and Images
These are the patterns that most often create real accessibility barriers in product interfaces.
Form labels and errors
Pass
Every input has a visible label connected with htmlFor/id, helpful instructions, and an error message connected with aria-describedby.
Fail
A form uses placeholder text as the only label and shows a red border with no text error.
Fix guidance: Labels must remain visible after typing. Error text should identify the problem and explain how to fix it.
Button names
Pass
Icon buttons include visible text or a clear aria-label such as aria-label="Delete report".
Fail
A trash icon button has no text, title, aria-label, or aria-labelledby.
Fix guidance: Buttons need a programmatic accessible name and must be reachable and usable with keyboard.
Link purpose
Pass
A link says "View June scan report" and points to the report page.
Fail
Several links say only "Click here" or "Read more" with no surrounding context.
Fix guidance: Link text should make sense in context. Avoid vague text that creates a screen reader links-list problem.
Image alternatives
Pass
Informative images include useful alt text. Decorative images use empty alt text.
Fail
A chart is inserted as an image with alt="chart" and no nearby data summary.
Fix guidance: Alt text should describe the image purpose. Complex images need adjacent explanation or data.
Structure, Tables, Modals, Alerts, and Navigation
Good structure makes pages faster to understand and easier to navigate with assistive technology.
Headings
Pass
The page has one h1, meaningful h2 sections, and h3 subsections that follow the visual hierarchy.
Fail
Headings are selected for font size and jump from h1 to h5.
Fix guidance: Use heading levels to describe document structure, then style them with CSS.
Data tables
Pass
The table includes a caption, column headers, row headers where useful, and cells that remain readable on mobile.
Fail
A layout table is used for spacing or a data table has no headers.
Fix guidance: Use table semantics only for tabular data. Associate header cells with data cells.
Modal dialogs
Pass
Opening the modal moves focus to the dialog, Escape closes it, background content is not reachable, and focus returns to the trigger.
Fail
The modal appears visually while keyboard focus stays behind it.
Fix guidance: A modal requires focus management, a visible close control, an accessible name, and predictable dismissal.
Alerts and status messages
Pass
A form error summary appears after submit and is announced without interrupting normal reading.
Fail
The entire page is wrapped in role="alert" so every update is announced loudly.
Fix guidance: Use alerts and live regions only for important dynamic updates.
Navigation
Pass
The site has a nav landmark, clear current-page state, a skip link, and consistent menu order.
Fail
Navigation changes order between pages or hides the active page from assistive technology.
Fix guidance: Consistent navigation helps people build a reliable mental model of the site.
Manual WCAG Testing Checklist
Use this quick checklist after automated scans. It is not a certification checklist, but it catches many issues that scanners cannot fully evaluate.
- Tab through the page and confirm focus order follows the visual reading order.
- Confirm focus is always visible and not hidden behind sticky headers, dialogs, or overlays.
- Use only the keyboard to open menus, submit forms, close modals, and recover from errors.
- Zoom to 200 percent and confirm content reflows without horizontal scrolling for normal page content.
- Check that text alternatives describe purpose, not just appearance.
- Confirm validation errors are textual, specific, connected to fields, and announced at the right time.
- Check that color is not the only way to identify required fields, errors, selected states, or chart values.