What Is WCAG 2.2 AA? Website Accessibility Guide
Published Aug 2, 2026 · 10 min read
Published by AKSIS· source and claim review documented
How this guide was reviewed
AKSIS publishes practical website and search guidance for small business owners. Each guide is reviewed for source support, claim boundaries, clarity, and small-business usefulness before production publication.
General information only—not legal, financial, medical, or platform policy advice.
Read the AKSIS editorial policy.
Is WCAG 2.3 the latest version?
No. As of August 2026, the latest completed W3C Recommendation is WCAG 2.2. WCAG 2.2 was updated as a Recommendation in December 2024 and adds criteria involving focus visibility, target size, dragging alternatives, consistent help, redundant entry, and accessible authentication. A future accessibility standard may change the version number, but a draft is not the same thing as a completed Recommendation.
What do Level A, AA, and AAA mean?
| Level | Meaning | Practical use |
|---|---|---|
| A | Foundational requirements that remove major barriers | Minimum baseline; not usually enough by itself |
| AA | Includes every Level A and Level AA criterion | Common engineering and organizational target |
| AAA | Includes A, AA, and AAA criteria | Useful for selected content; W3C does not recommend requiring it for an entire site as a general policy |
What makes a business website accessible?
Accessible implementation lets more people understand the content and complete the same important tasks. That includes people who navigate by keyboard, enlarge text, use screen readers, need captions, have limited color perception, use voice input, or need more predictable interactions.
- Semantic headings, landmarks, lists, tables, buttons, links, and form controls.
- Keyboard access with a logical order and focus that remains visible and unobscured.
- Text and controls with sufficient contrast without using color as the only signal.
- Useful image alternatives, captions, transcripts, and labels where the content requires them.
- Layouts that reflow at narrow widths and remain usable with browser zoom and larger text.
- Clear instructions and errors that identify the problem and explain how to fix it.
- Reduced-motion support and touch targets that do not require unusually precise movement.
Can an automated accessibility scan prove compliance?
No. Automated tools are valuable because they consistently detect certain missing names, contrast failures, structural problems, and invalid relationships. They cannot decide whether alt text communicates the right meaning, a focus order makes sense, instructions are understandable, or a complex task works well with assistive technology.
The W3C explains that no tool alone can determine whether a site meets accessibility standards. The U.S. Department of Justice similarly advises pairing automated checks with manual review. A clean automated score is evidence from one test condition—not a permanent certification.
How should keyboard and focus testing work?
Start at the browser address bar and use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape where appropriate. Every interactive control should be reachable and usable without a mouse. Focus should follow a sensible path, remain visually obvious, and not disappear behind a sticky header or open panel. Menus, accordions, forms, and error states should expose the same task to keyboard users that pointer users receive.
Does every image need descriptive alt text?
Every image needs an accessibility decision, but not every image needs a written description. Informative images need text that communicates their purpose in context. A decorative image that adds no information should usually use an empty alternative so a screen reader can skip it. Charts, diagrams, and screenshots may need nearby explanations or longer descriptions when the important information cannot fit into concise alt text.
Do mobile and desktop versions both need testing?
Yes. WCAG conformance applies to the complete page, including responsive variations. A desktop page can work correctly while its mobile menu, sticky controls, text wrapping, or touch targets create barriers. Testing should include narrow reflow, browser zoom, larger text, portrait and landscape behavior, keyboard use, and common mobile screen-reader conditions where the project requires them.
What about booking tools, payment pages, maps, and widgets?
Third-party interfaces remain part of the customer journey even when another company supplies the code. Review the provider before integration, choose the strongest practical option, configure it correctly, and document any known limitation or alternative contact path. The website owner cannot fix every vendor interface, but ignoring a barrier because it comes from a widget does not help the person trying to book or pay.
How often should accessibility be checked?
Check early during design, during component development, before launch, after meaningful template or integration changes, and on an ongoing sample of important pages and tasks. Content editors can introduce barriers through new images, headings, links, documents, videos, or embeds even when the original code was strong. Accessibility is closer to maintenance and quality control than a one-time launch checkbox.
Does WCAG 2.2 AA guarantee legal compliance?
No single technical checklist answers every legal question. The Department of Justice web-accessibility guidance describes accessibility responsibilities for covered organizations and points to WCAG as useful technical guidance. Applicable duties can depend on the organization, jurisdiction, service, content, contracts, and current law. A developer can implement and document technical requirements; qualified counsel should answer organization-specific legal questions.
How AKSIS makes the process easier
- Plan: identify critical pages, forms, booking paths, media, documents, third-party tools, and approved requirements.
- Build: use semantic components, keyboard-operable controls, responsive layouts, visible focus, appropriate labels, and reduced-motion support.
- Test: combine automated scanning with keyboard, zoom/reflow, contrast, form, link, and screen-reader spot checks appropriate to the scope.
- Document: record the standard, test conditions, remaining limitations, owners, and practical alternatives.
- Maintain: retest important templates and customer tasks when the site, content, or integrations change.
AKSIS does not sell a permanent compliance badge. We sell an accountable implementation and testing process, clear documentation, and ongoing help when the agreed service includes it. Read our current accessibility statement or see how accessibility fits into a website build.