Understand WCAG and test specific barriers
The Web Content Accessibility Guidelines (WCAG) describe requirements for accessible web content. Find the basics and practical guides to forms, keyboard access, contrast and other topics.
Which problem do you want to solve?
Choose a topic. The linked guides provide test steps and code examples.
Forms & interaction
Forms, Labels & Error Validation
Labels and error messages should tell you what to enter and how to correct mistakes.
Keyboard Focus, Modals & Dialogs
Check whether you can operate, close and leave dialogs and cookie banners with a keyboard.
Focus Visible & Focus Not Obscured
A sticky header must not entirely hide focused elements; additional requirements apply to the focus indicator’s appearance.
Touch Target Sizes & Gestures
Check target size and spacing: 2.5.8 (AA) requires 24 × 24 CSS pixels or a defined exception; 2.5.5 (AAA) sets a higher target.
Accessible Authentication & 2FA
Check whether people can sign in using a password manager, paste or a suitable alternative without a cognitive function test.
Status messages after an action
Success, progress and result counts need to be perceivable without moving focus.
Contrast & presentation
Text contrast & themes
Check text contrast in both themes: usually 4.5:1, or 3:1 for large text; the guide explains exceptions.
Non-text contrast: borders, focus & icons
Check essential borders, icons and state indicators for 3:1 against adjacent colors; a text contrast scan does not cover this.
Content & orientation
Semantic HTML & Practical ARIA Usage
Check whether browsers and assistive technology can identify control names, roles and states.
Images, Icons & Meaningful Text Alternatives
Check whether image alternatives convey the image’s purpose and decorative images are skipped with empty alt text.
Accessible Links & Action Buttons
Check whether people can understand a link or button’s purpose from its label and permitted context.
Navigation, Headings & Skip Links
Check whether headings and page regions support orientation and repeated navigation can be bypassed.
WCAG Explained: Structure, Levels, and Versions
Four principles organize WCAG: perceivable, operable, understandable and robust. Success criteria turn them into specific requirements, each assigned a level of A, AA or AAA.
Structure hierarchy
WCAG → 4 Principles → Guidelines → Success Criteria → Level A, AA, or AAA
A guideline groups a topic, such as keyboard access. Its success criteria describe what needs to be checked.
The Four WCAG Principles (POUR)
- Perceivable
- Can people perceive the information through their senses?
- Operable
- Can people operate all interactive functions?
- Understandable
- Are user interfaces and processes clear and predictable?
- Robust
- Can browsers and assistive technologies interpret the interface reliably?
What Do Levels A, AA, and AAA Mean?
AA includes every criterion at levels A and AA. AAA adds further requirements. The version and level you need depend on the agreed or applicable assessment standard.
| Level | Simply Explained | Practical Significance |
|---|---|---|
| Level A | Basic requirements | For example, text alternatives and keyboard operation. |
| Level AA | Requirements in addition to Level A | A testing target for many web projects; check the applicable assessment standard. |
| Level AAA | Requirements in addition to Level AA | For example, enhanced text contrast (1.4.6) and focus appearance (2.4.13). |
What Is the Difference Between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 adds nine success criteria to WCAG 2.1. The former criterion 4.1.1 (Parsing) was removed. Check which version applies to your project’s contract or legal requirements.
- WCAG 2.1
Enhanced earlier versions with requirements for mobile devices and responsive layouts.
Touch gestures, screen orientation, text spacing, responsive reflow without horizontal scrolling.
- WCAG 2.2
Builds on WCAG 2.1 with criteria addressing modern UI components and cognitive load.
Focus Not Obscured (2.4.11), Target Size Minimum (2.5.8), Accessible Authentication without cognitive tests (3.3.8).
Before / after: Label a form field
An associated label names the field and stays visible while typing. Its for attribute must match the input’s id.
Before: Missing label
<input type="email" name="email">After: Label associated with the field
<label for="email">
Email address
</label>
<input type="email" id="email"
name="email" autocomplete="email">Test important tasks and prioritize findings
Start with tasks people need to complete on your website: buying, registering, signing in or contacting you.
Address blocked tasks first
Prioritize errors by their effect on use. An unreachable buy button or a keyboard trap can prevent a task. Record affected pages, states and reproducible steps.
From finding to retest
Define the scope
Choose pages, devices and states. Record areas you could not reach or test.
Test and fix
Combine automated checks with manual tests. Give developers findings with locations and reproduction steps.
Retest and document
Repeat affected tests after fixes. Record results, testing scope and remaining barriers.
Automated and manual checks
Automated checks find machine-evaluable problems such as missing names, invalid ARIA or text contrast in the reached state. Essential borders, icons and states also need targeted non-text contrast evaluation.
Test complete tasks with a keyboard and screen reader. Image descriptions, understandable errors and whether all important states were reached need contextual evaluation. A scan does not establish full conformance.
Who checks what?
- Development
Check HTML, accessible names, keyboard operation and focus changes in the affected components.
Explore forms and interaction- Design
Check readability, contrast, target sizes and the appearance of focus, errors and selection.
Explore contrast and presentation- Product & agencies
Define important tasks, test states and responsibilities. Plan fixes and document unresolved barriers.
Go to priorities
Test and follow up with navable
Use Audit to collect findings from tested pages and states. Developer tools help you address them; audit data can support a statement draft.
More tools and guides
Set up Local MCP
The open-source Local MCP can check localhost without a navable account. The setup guide explains the configuration for your IDE.
Set up Local MCPStandards and original sources
The original sources contain criteria, exceptions and explanations. Each topic guide links to the relevant source for its details.