What is the difference between WCAG Level A, AA, and AAA?

Level A is the minimum. It covers requirements that block access entirely (keyboard traps, missing alt text, seizure-inducing flashes). Level AA adds requirements that affect a wider range of disabilities (contrast ratios, reflow, focus visibility). Level AA is the standard most organizations target and what most regulations require. Level AAA is aspirational and covers enhanced requirements (7:1 contrast, sign language for video). Few products achieve full AAA conformance.

How long does an accessibility audit take?

A focused audit of one page or flow takes 3-5 hours (1 hour automated scanning, 2-4 hours manual testing). A full product audit for a medium-sized SaaS application typically takes 2-4 weeks of dedicated effort. Start with the highest-traffic pages and the most critical user flows.

Can automated tools replace manual testing?

No. Automated scanners catch approximately 30-40% of WCAG issues (missing alt text, contrast failures, ARIA errors). They cannot test whether alt text is meaningful, whether keyboard interaction is logical, whether screen reader announcements make sense in context, or whether the visual reading order matches the DOM order. Always supplement automated scans with keyboard and screen reader testing.

Who is responsible for accessibility?

Everyone. Designers own contrast, focus states, and semantic structure in mockups. Engineers own implementation (HTML semantics, ARIA attributes, keyboard handling). PMs own the requirement that accessibility is part of the [definition of done](/glossary/acceptance-criteria). QA owns testing with assistive technologies. An accessibility audit is a team deliverable, not one person's job.

Do native mobile apps need WCAG compliance?

WCAG applies to web content, but the principles translate directly. iOS uses the Accessibility API (VoiceOver, Dynamic Type, Reduce Motion). Android uses TalkBack and the Accessibility Scanner. The [mobile app design checklist](/templates) covers platform-specific accessibility requirements alongside general UX patterns. ---

Accessibility Audit Template

What This Template Is For

An accessibility audit evaluates a product against WCAG 2.1 success criteria to ensure it is usable by people with disabilities. This is not optional polish. In the US, the ADA and Section 508 create legal exposure for inaccessible digital products. In the EU, the European Accessibility Act (EAA) takes effect June 2025. Beyond compliance, accessible products serve more users. Roughly 15-20% of the global population has some form of disability, and many accessibility improvements (keyboard navigation, clear labels, sufficient contrast) make the product better for everyone.

This template organizes the audit around WCAG's four principles: Perceivable, Operable, Understandable, and Robust (POUR). Each section contains specific checkpoints with pass/fail criteria. It is structured at the AA conformance level, which is the standard most organizations target. AAA criteria are noted where relevant but not required for AA compliance.

This template pairs well with the UX audit template for general usability issues and the design system documentation template for embedding accessibility standards into reusable components. For broader product quality evaluation, the AI UX Audit tool can flag common accessibility issues automatically. Teams following structured product discovery should include accessibility audits at the prototype and pre-launch stages.

How to Use This Template

Define the scope. Audit one flow, page, or component set at a time. A full-product audit is best broken into sections across multiple sessions.
Set up your testing environment. You need: a screen reader (VoiceOver on Mac, NVDA on Windows), keyboard-only navigation, a color contrast checker (WebAIM Contrast Checker or browser DevTools), and an automated scanner (axe DevTools or Lighthouse).
Run automated tools first. They catch roughly 30-40% of issues (contrast, missing alt text, ARIA errors). Manual testing catches the rest.
Walk through each checkpoint manually. Test with keyboard only. Test with a screen reader. Resize to 200%. Use Windows High Contrast mode.
Log each failure with the WCAG criterion, severity, evidence (screenshot or recording), and a recommended fix.
Prioritize fixes by severity and legal risk. Level A failures are the highest priority (they block basic access). Level AA failures are next.

The Template

Audit Metadata

Field	Details
Product / Feature	[Name]
Auditor	[Name]
Date	[Date]
Scope	[Pages, flows, or components audited]
Target conformance	WCAG 2.1 Level AA
Testing tools	[e.g., axe DevTools 4.8, VoiceOver, NVDA, WebAIM Contrast Checker]
Browsers tested	[e.g., Chrome 122, Firefox 123, Safari 17]
Assistive technologies	[e.g., VoiceOver macOS, NVDA Windows]

Principle 1: Perceivable

Information and UI components must be presentable in ways users can perceive.

1.1 Text Alternatives

☐ All images have descriptive alt text (1.1.1 Level A)
☐ Decorative images use alt="" or role="presentation" (1.1.1 Level A)
☐ Complex images (charts, diagrams) have extended descriptions (1.1.1 Level A)
☐ Icon buttons have accessible labels (via aria-label or visually hidden text) (1.1.1 Level A)
☐ Form inputs have associated elements (1.1.1 Level A)

1.2 Time-Based Media

☐ Pre-recorded video has captions (1.2.2 Level A)
☐ Pre-recorded audio has a transcript (1.2.1 Level A)
☐ Live video has real-time captions (1.2.4 Level AA)
☐ Pre-recorded video has audio description (1.2.5 Level AA)

1.3 Adaptable

☐ Content structure uses semantic HTML (headings, lists, landmarks) (1.3.1 Level A)
☐ Reading order is meaningful when CSS is disabled (1.3.2 Level A)
☐ Instructions do not rely solely on shape, size, or visual position (1.3.3 Level A)
☐ Content adapts to portrait and landscape orientation (1.3.4 Level AA)
☐ Input purpose is identified for autofill fields (1.3.5 Level AA)

1.4 Distinguishable

☐ Text has minimum 4.5:1 contrast ratio (normal text) (1.4.3 Level AA)
☐ Large text has minimum 3:1 contrast ratio (1.4.3 Level AA)
☐ Non-text elements (icons, borders, focus rings) have 3:1 contrast (1.4.11 Level AA)
☐ Color is not the only means of conveying information (1.4.1 Level A)
☐ Text can be resized to 200% without loss of content (1.4.4 Level AA)
☐ Content reflows at 320px width without horizontal scrolling (1.4.10 Level AA)
☐ Text spacing can be adjusted without breaking layout (1.4.12 Level AA)
☐ Content on hover or focus is dismissible, hoverable, and persistent (1.4.13 Level AA)

Principle 2: Operable

UI components and navigation must be operable by all users.

2.1 Keyboard Accessible

☐ All interactive elements are reachable via Tab key (2.1.1 Level A)
☐ Focus order follows a logical sequence (2.4.3 Level A)
☐ No keyboard traps (user can always Tab away) (2.1.2 Level A)
☐ Custom components (dropdowns, modals, date pickers) support keyboard interaction (2.1.1 Level A)
☐ Focus is visible on all interactive elements (2.4.7 Level AA)

2.2 Enough Time

☐ Time limits can be extended, adjusted, or turned off (2.2.1 Level A)
☐ Auto-updating content can be paused or stopped (2.2.2 Level A)

2.3 Seizures and Physical Reactions

☐ No content flashes more than 3 times per second (2.3.1 Level A)

2.4 Navigable

☐ Skip navigation link is provided (2.4.1 Level A)
☐ Pages have descriptive titles (2.4.2 Level A)
☐ Link text describes the destination (no "click here") (2.4.4 Level A)
☐ Multiple ways to find pages (nav, search, sitemap) (2.4.5 Level AA)
☐ Headings and labels describe their content (2.4.6 Level AA)

2.5 Input Modalities

☐ Touch targets are at least 24x24px (2.5.8 Level AA)
☐ Functionality is not limited to specific motion gestures (2.5.4 Level A)

Principle 3: Understandable

Information and UI operation must be understandable.

3.1 Readable

☐ Page language is specified via lang attribute (3.1.1 Level A)
☐ Language changes within content are marked (3.1.2 Level AA)

3.2 Predictable

☐ Navigation is consistent across pages (3.2.3 Level AA)
☐ Components that function the same are identified consistently (3.2.4 Level AA)
☐ Focus changes do not trigger unexpected context changes (3.2.1 Level A)

3.3 Input Assistance

☐ Errors are identified and described in text (3.3.1 Level A)
☐ Labels and instructions are provided for inputs (3.3.2 Level A)
☐ Error suggestions are provided when possible (3.3.3 Level AA)
☐ Submissions can be reviewed, confirmed, or reversed (3.3.4 Level AA)

Principle 4: Robust

Content must be robust enough for assistive technologies to interpret.

4.1 Compatible

☐ HTML validates without significant parsing errors (4.1.1 Level A)
☐ Custom components have appropriate ARIA roles, states, and properties (4.1.2 Level A)
☐ Status messages are announced by screen readers without receiving focus (4.1.3 Level AA)
☐ ARIA attributes reference existing element IDs (4.1.2 Level A)

Findings Log

#	WCAG Criterion	Level	Severity	Finding	Element	Recommendation
1	[e.g., 1.4.3]	A / AA	[Critical/Major/Minor]	[What fails]	[Selector or component]	[How to fix]
2	[Criterion]	[Level]	[Severity]	[Finding]	[Element]	[Fix]

Summary

Automated scan results: [# of issues found by axe/Lighthouse]

Manual testing results: [# of additional issues found]

Total findings: [Count]

By level: Level A failures: [n] | Level AA failures: [n]

By severity: Critical: [n] | Major: [n] | Minor: [n]

Conformance assessment:

☐ Passes WCAG 2.1 Level A
☐ Passes WCAG 2.1 Level AA
☐ Partially conforms (list exceptions)
☐ Does not conform (list blocking issues)

Filled Example: SaaS Settings Page

Audit Metadata

Field	Details
Product / Feature	Acme Analytics: Settings Page
Auditor	Jordan Lee
Date	March 2026
Scope	Profile settings, notification preferences, team management
Target conformance	WCAG 2.1 Level AA
Testing tools	axe DevTools 4.8, VoiceOver 15, WebAIM Contrast Checker

Key Findings

#	WCAG Criterion	Level	Severity	Finding	Recommendation
1	2.1.2	A	Critical	Custom date picker traps keyboard focus. Users cannot Tab out without clicking.	Replace with accessible date picker (react-datepicker or native input type="date").
2	1.4.3	AA	Major	Placeholder text in form fields has 2.8:1 contrast ratio (needs 4.5:1).	Darken placeholder color from #999 to #767676.
3	4.1.3	AA	Major	"Settings saved" toast is not announced by screen readers.	Add `role="status"` and `aria-live="polite"` to the toast container.
4	1.4.1	A	Major	Required fields are indicated only by red border color. No text or icon indicator.	Add "(required)" text label or asterisk with screen-reader-accessible legend.
5	2.4.7	AA	Minor	Focus ring is not visible on the "Save" button in high contrast mode.	Add `outline: 2px solid` on `:focus-visible` that persists in forced-colors mode.

Conformance assessment: Does not conform to Level A (keyboard trap in date picker). Partially conforms to Level AA (3 additional failures).

Key Takeaways

Target WCAG 2.1 Level AA as the minimum standard for compliance and usability
Run automated scanners first, then validate manually with keyboard and screen reader testing
Level A failures block basic access and must be fixed before release
Embed accessibility checks into your design system so new components are accessible by default
Accessibility benefits all users, not only users with disabilities

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Accessibility Audit Template