// Accessibility
Website Accessibility Checklist 2026: WCAG 2.2 in Plain English
A practical WCAG 2.2 accessibility checklist for 2026: color contrast, keyboard navigation, screen reader compatibility, form labels, and the checks that matter most for compliance and usability.
Why accessibility is a business issue, not just a compliance one
One in six people worldwide has some form of disability — visual, motor, cognitive, or auditory. That's roughly 1.3 billion potential visitors who may struggle to use a site that hasn't considered their needs. The business case is straightforward: accessibility expands your addressable audience, reduces bounce rates among users who would otherwise leave in frustration, and increasingly reduces legal risk — US ADA lawsuits against inaccessible websites exceeded 4,000 in 2024 alone.
WCAG 2.2 (Web Content Accessibility Guidelines, published October 2023) is the current international standard. Level AA conformance is what most legal requirements reference and what most accessibility audits target. It's not a ceiling — Level AAA is more rigorous — but AA gives you 90% of the practical accessibility benefit and keeps you out of legal jeopardy in most jurisdictions.
Visual accessibility: contrast, text, and layout
Visual accessibility failures are the most common category and the easiest to catch with automated tools. They're also among the easiest to fix — contrast adjustments and font size changes require no structural changes to your HTML.
- Color contrast: body text needs a 4.5:1 contrast ratio against its background. Large text (18pt+ or 14pt bold) needs 3:1. UI components and focus indicators need 3:1. Test with WebAIM's Contrast Checker or run an automated audit
- Don't rely on color alone: if your error messages are only red text with no icon or label, colorblind users can't distinguish them from regular text
- Text resize: the page must remain usable when text is zoomed to 200% without requiring horizontal scrolling or losing content
- Reflow: at 400% zoom (or a 320px viewport), content should reflow into a single column without loss of information. This matters for low-vision users who work at high magnification
- Avoid text in images: image text can't be resized, doesn't work with screen readers, and breaks at zoom levels. Put text in HTML, style it with CSS
- New in WCAG 2.2 — Focus appearance (2.4.11): visible focus indicators must have a minimum contrast of 3:1 and a minimum area of the perimeter of the component
Keyboard and motor accessibility
Many users navigate entirely by keyboard — people with motor disabilities, power users, and screen reader users who rely on keyboard commands to navigate content. If an interaction requires a mouse, you've excluded all of them.
- All interactive elements reachable by Tab: buttons, links, form fields, modal dialogs, dropdown menus — everything clickable must also be reachable via keyboard
- Visible focus indicators: never use outline: none on focused elements without a custom replacement. Users need to see where keyboard focus is
- Logical focus order: Tab should move through elements in a reading order that makes sense — left to right, top to bottom — matching the visual layout
- No keyboard traps: if focus enters a modal or widget, it must be possible to exit using only the keyboard (Escape to close modals is the standard)
- New in WCAG 2.2 — Dragging alternatives (2.5.7): if a function uses drag-and-drop, provide an alternative that works with a single pointer or keyboard
- New in WCAG 2.2 — Target size (2.5.8): interactive elements must have a minimum target size of 24x24 CSS pixels, with exceptions for inline links
Screen reader and semantic HTML
Screen readers convert your page to audio or braille output. They depend entirely on the semantic information in your HTML to describe what each element is and how it relates to surrounding content. Visual design can compensate for poor semantics on screen; audio cannot.
- One H1 per page: use heading levels (H1–H6) to convey document hierarchy, not visual styling. A user navigating by headings should get an accurate outline of the page
- Descriptive link text: 'Read more' and 'Click here' are meaningless out of context. Screen readers can list all links on a page — every link text should make sense in isolation
- Alt text on meaningful images: describe what the image communicates, not what it shows. A chart of sales growth: 'Line chart showing 40% revenue growth from Q1 to Q3 2026,' not 'chart.png'
- Form labels: every input needs a programmatically associated label — not just a placeholder (which disappears on focus) and not just visual proximity. Use <label for='id'> or aria-labelledby
- ARIA landmarks: wrap your page in semantic regions (<main>, <nav>, <header>, <footer>) so screen reader users can jump directly to content
- Dynamic content announcements: if content changes without a page reload (modals, loading states, error messages), use aria-live regions so screen readers announce the change
Try it: audit your site's accessibility score
Automated tools catch about 30–40% of accessibility issues — the objective, measurable ones like contrast ratios and missing alt text. The rest require human judgment about whether content is understandable and whether interactions are operable in practice.
WebEnture's Accessibility Agent (/accessibility-agent) runs an automated WCAG 2.2 AA audit across your entire site — checking contrast, heading structure, form labels, link text, ARIA usage, and keyboard accessibility patterns — and scores each page. Use it to catch the low-hanging fruit fast, then prioritize manual testing on your most critical flows: signup, checkout, and your top landing pages.