How to Audit Your Website for WCAG 2.2 AA in 30 Minutes in 2026

A focused, practical walkthrough for catching the most common accessibility failures fast.

Last updated: 2026-05-15 05:02 UTC 10 min read

Key Takeaways

What You Can (and Cannot) Accomplish in 30 Minutes
Minutes 1-8: Run an Automated Accessibility Scan
Minutes 8-16: Test Keyboard Navigation
Minutes 16-22: Check Document Structure and Semantics
Minutes 22-27: Test Forms and Interactive Components

What You Can (and Cannot) Accomplish in 30 Minutes

A full WCAG 2.2 AA audit by an accessibility specialist takes days. It involves testing with multiple screen readers, documenting every failure against specific success criteria, and writing remediation guidance for each issue. That is not what this guide is.

This guide is a focused 30-minute triage that catches the most common and most impactful accessibility failures. Research from WebAIM's annual accessibility analysis shows that the same six categories of issues account for over 95% of detected accessibility errors on the top million websites: missing alternative text, low contrast text, missing form labels, empty links, missing document language, and empty buttons. You can check for all of these and more in 30 minutes.

This audit will not make your site fully WCAG 2.2 AA compliant. What it will do is identify the issues that affect the most users and are the most likely to generate complaints or legal risk. Think of it as an accessibility triage, not a comprehensive assessment. After this 30-minute pass, you will know your biggest gaps and can prioritize deeper testing for the areas that need it.

What you need before starting:

Google Chrome with the axe DevTools extension installed
A keyboard (you will be testing without a mouse for one section)
The HeadingsMap extension for Chrome (optional but helpful)
A timer (seriously, time yourself to stay focused)

Minutes 1-8: Run an Automated Accessibility Scan

Start with automated testing because it covers the most ground in the least time. Automated tools catch roughly 30-40% of WCAG issues, but they catch the easy ones that should never ship.

Step 1: Open axe DevTools. Navigate to your most important page (usually the homepage or the primary user-facing page). Open Chrome DevTools (F12), go to the axe DevTools tab, and click "Scan ALL of my page." This takes 5-15 seconds.

Step 2: Review the results. axe categorizes issues by impact level: Critical, Serious, Moderate, and Minor. Focus on Critical and Serious issues first. The most common findings are:

Images missing alt text: Every <img> needs an alt attribute. Informative images need descriptive alt text. Decorative images need alt="" (empty, not missing).
Insufficient color contrast: Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text, defined as 18pt or 14pt bold). axe flags each failing element and tells you the exact ratio.
Form inputs without labels: Every <input>, <select>, and <textarea> needs an associated <label>. Placeholder text is not a label.
Empty links or buttons: A link or button with no text content and no aria-label is invisible to screen readers. Common with icon-only buttons.
Missing page language: The <html> element must have a lang attribute (e.g., lang="en").

Step 3: Scan 2-3 additional pages. At minimum, scan a page with forms (contact, checkout, login), a content-heavy page (blog post, documentation), and a page with interactive components (dashboard, settings). Different page types often have different accessibility issues. Record the total issue count and the critical/serious breakdown for each page.

If you want a command-line alternative, run axe-core directly with npx @axe-core/cli https://your-site.com to get a terminal-based report.

Minutes 8-16: Test Keyboard Navigation

Put your mouse in a drawer. For the next 8 minutes, you are navigating your site with only a keyboard. This single test catches more real-world accessibility barriers than any automated tool.

Essential keyboard controls:

Tab - Move focus to the next interactive element
Shift + Tab - Move focus to the previous interactive element
Enter - Activate links and buttons
Space - Activate buttons, toggle checkboxes, open dropdowns
Arrow keys - Navigate within components (radio groups, tabs, menus)
Escape - Close modals, menus, and popups

What to check as you tab through the page:

Can you see where focus is? Every interactive element must have a visible focus indicator (outline, highlight, border change). If you press Tab and cannot tell where focus moved, that is a WCAG 2.4.7 failure. Many sites use outline: none in CSS without providing an alternative focus style. This is one of the most common and most damaging accessibility mistakes.
Can you reach every interactive element? Tab through the entire page. Every link, button, form field, dropdown, tab panel, and interactive widget must be reachable. If something is clickable with a mouse but not reachable with Tab, it is likely a <div> or <span> with a click handler instead of a proper <button> or <a> element.
Is the tab order logical? Focus should move through the page in a reading order that makes sense: top to bottom, left to right (for LTR languages), following the visual layout. If focus jumps from the header to the footer and then back to the sidebar, the tab order is broken.
Can you open and close menus? Open the main navigation menu with Enter or Space. Can you navigate within it using arrow keys or Tab? Can you close it with Escape?
Can you escape modals? If your site has modal dialogs, open one. Focus should be trapped inside the modal (Tab should not move focus to elements behind it). Escape should close it. When closed, focus should return to the element that opened it.
Are there keyboard traps? A keyboard trap is any situation where you can Tab into an element but cannot Tab out of it. Custom video players, embedded iframes, and WYSIWYG editors are common trap locations. If you get stuck, that is a WCAG 2.1.2 failure (which is a Level A criterion, meaning it is even more fundamental than AA).

Minutes 16-22: Check Document Structure and Semantics

Screen reader users navigate by headings, landmarks, and links. If your document structure is wrong, it is like giving a sighted user a page with no visual hierarchy: technically all the content is there, but it is unusable.

Check heading hierarchy: Open the HeadingsMap extension (or use the axe DevTools heading structure view). The page should have exactly one <h1> that describes the page's primary content. Headings should not skip levels: an <h2> should not be followed by an <h4> without an <h3> in between. Headings should not be used solely for visual styling. If a heading exists only because the designer wanted large bold text, the correct fix is CSS, not an <h2> tag.

Check landmark regions: Open Chrome DevTools, go to the Elements panel, and verify these landmark elements exist:

<header> or role="banner" - Site header
<nav> or role="navigation" - Main navigation (multiple navs should have distinct aria-label values)
<main> or role="main" - Primary page content
<footer> or role="contentinfo" - Site footer

You can quickly inspect landmarks by running this in the Chrome DevTools console:

document.querySelectorAll('header, nav, main, footer, aside, [role="banner"], [role="navigation"], [role="main"], [role="contentinfo"], [role="complementary"]').forEach(el => console.log(el.tagName, el.getAttribute('role'), el.getAttribute('aria-label')));

Check link text: Scan the page for links that say "click here," "read more," "learn more," or similar vague text. Screen reader users often navigate by pulling up a list of all links on the page. A list of 15 links that all say "Read more" is useless. Each link should make sense out of context. If you must use generic text, add an aria-label that provides context: <a href="/pricing" aria-label="Read more about our pricing plans">Read more</a>.

Check skip navigation: Press Tab once from the very top of the page. The first focusable element should be a "Skip to main content" link. This link can be visually hidden until focused. Click it (press Enter) and verify that focus moves to the main content area, bypassing the header and navigation. If this link does not exist, keyboard and screen reader users must Tab through the entire navigation on every page load.

Minutes 22-27: Test Forms and Interactive Components

Navigate to the most important form on your site (login, contact, checkout, signup) and check these items. Forms are where accessibility failures most directly prevent people from completing tasks.

Label associations: Click on the text label next to each form field. If clicking the label moves focus to the field, the label is properly associated. If clicking the label does nothing, the <label> element is missing its for attribute or is not wrapping the input. Check this for every field, including checkboxes and radio buttons.

Error handling: Submit the form with invalid or missing data. Check that:

Error messages are visible and adjacent to the fields they describe
Error messages are programmatically associated with their fields using aria-describedby or aria-errormessage
The error summary or first error field receives focus after submission, so screen reader users know something went wrong
Errors are not communicated only through color (e.g., a red border alone is not sufficient; there must also be text or an icon)

Required fields: Verify that required fields are indicated both visually (asterisk or "required" text) and programmatically (aria-required="true" or the HTML required attribute).

Custom interactive components: If your site uses custom dropdowns, date pickers, accordions, tabs, or other interactive widgets, test each one with keyboard only. Custom components are the most common source of accessibility failures because developers often build the visual experience without implementing the keyboard interaction pattern or ARIA attributes. A custom dropdown, for example, should use role="listbox", role="option", aria-expanded, and respond to arrow keys. Check the WAI-ARIA Authoring Practices Guide patterns for the expected keyboard behavior of each widget type.

Quick ARIA check: Open DevTools and search the source for aria- attributes. Look for obvious misuse: aria-hidden="true" on visible interactive elements (makes them invisible to screen readers), aria-label on elements that already have visible text (potentially confusing), or role="button" on elements without keyboard handlers.

Minutes 27-30: Check Media, Motion, and Responsive Accessibility

The final three minutes cover areas that are increasingly important in WCAG 2.2 and frequently overlooked.

Images and media:

Confirm that all informative images have meaningful alt text (not just the filename). Open DevTools and run: document.querySelectorAll('img').forEach(img => console.log(img.src.split('/').pop(), '|', img.alt));
If the page has video content, verify captions exist. Play the video and check that captions are accurate and synchronized.
If the page has audio-only content (podcasts), verify a transcript is available.

Motion and animation (WCAG 2.3.3):

Check whether your site respects prefers-reduced-motion. In Chrome DevTools, open the Command Palette (Ctrl+Shift+P), type "reduced motion," and select "Emulate CSS prefers-reduced-motion: reduce." Animations should stop or simplify. If your site has autoplay video, parallax scrolling, or complex CSS animations, they should all respect this setting.
Look for any content that flashes more than 3 times per second (WCAG 2.3.1, Level A seizure risk criterion). This is rare but critical.

Target size (WCAG 2.5.8, new in 2.2): WCAG 2.2 added a target size requirement: interactive targets must be at least 24x24 CSS pixels, with some exceptions. Check your mobile navigation links, icon buttons, and form controls on a phone-sized viewport. Small touch targets are both an accessibility failure and a usability problem for everyone.

Text resizing: Use your browser's zoom function (Ctrl + Plus) to increase the page to 200%. Verify that no content is cut off, overlapping, or hidden. All text should remain readable and all functionality should remain usable. This tests WCAG 1.4.4 (Resize Text). Then check 400% zoom, which is required under WCAG 1.4.10 (Reflow). At 400% zoom (or equivalently, a 320px viewport width), the page should reflow to a single column with no horizontal scrolling.

After the Audit: Prioritize and Plan Remediation

You now have a list of issues from automated scanning, keyboard testing, and manual checks. Here is how to turn that into action.

Prioritize by impact and effort:

Fix immediately (high impact, low effort): Missing alt text, missing form labels, missing page language, color contrast failures, missing focus styles. These are typically one-line fixes.
Fix this sprint (high impact, medium effort): Keyboard traps, missing skip navigation, broken heading hierarchy, form error handling. These require more changes but affect many users.
Plan for next sprint (high impact, high effort): Custom component accessibility (rebuilding a dropdown or date picker), video captions for existing content, reduced motion support. These take real development time.
Track and schedule (lower impact): Link text improvements, landmark region additions, ARIA refinements. Important but less urgent than the above categories.

Document your findings: Record each issue with the page URL, a description of the problem, the WCAG success criterion it violates (e.g., "1.4.3 Contrast Minimum"), the severity, and a suggested fix. Use a visual feedback tool like Marker.io to capture annotated screenshots with browser metadata, which makes it much easier for developers to locate and reproduce each issue.

Schedule regular audits: This 30-minute audit is not a one-time event. Run it after every major release, every design system update, and every time you add a new page template. Integrate automated accessibility checks (axe-core, Pa11y) into your CI pipeline to catch regressions between manual audits. Over time, the number of issues found in each audit should decrease as accessibility becomes part of your team's development habits.

When to bring in a specialist: If your site has legal compliance requirements (ADA, Section 508, European Accessibility Act), handles sensitive use cases (healthcare, government, finance), or you need a formal VPAT (Voluntary Product Accessibility Template), this 30-minute audit is a starting point, not a finish line. Hire an accessibility specialist for a comprehensive audit and ongoing consulting.

Frequently Asked Questions

Is WCAG 2.2 AA a legal requirement?

It depends on your jurisdiction. In the US, the ADA has been interpreted by courts to apply to websites. The European Accessibility Act (effective June 2025) explicitly requires WCAG 2.1 AA for many digital products and services. Even where not legally mandated, WCAG AA is the widely accepted standard for web accessibility.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine new success criteria on top of WCAG 2.1, including requirements for focus appearance, dragging movements, target size, consistent help placement, and accessible authentication. Meeting WCAG 2.2 AA means you also meet 2.1 AA.

Can automated tools catch all accessibility issues?

No. Automated tools like axe DevTools catch approximately 30-40% of WCAG issues, primarily those that can be detected by inspecting the DOM. They cannot evaluate whether alt text is meaningful, whether keyboard interaction patterns make sense, or whether content is cognitively clear. Manual testing is required for full coverage.

Do I need to test with a screen reader?

For a comprehensive audit, yes. For this 30-minute triage, keyboard testing catches most of the same issues that screen reader testing would reveal. If you want to add a quick screen reader check, use VoiceOver on Mac (Cmd+F5) or NVDA on Windows (free download) and navigate one key page to listen for obvious issues.

How often should I run accessibility audits?

Run automated scans on every pull request via your CI pipeline. Perform this 30-minute manual audit after every major release or design change. Schedule a comprehensive professional audit annually or whenever you launch a major new feature or redesign.

Resources and Further Reading

axe DevTools Chrome Extension Free browser extension for automated accessibility scanning. Catches WCAG violations and provides remediation guidance.
WCAG 2.2 Quick Reference Filterable reference of all WCAG 2.2 success criteria with techniques and examples for meeting each requirement.
WebAIM Contrast Checker Enter foreground and background colors to check if they meet WCAG AA and AAA contrast requirements.
WAI-ARIA Authoring Practices Guide Patterns and examples for building accessible interactive components including tabs, menus, dialogs, and more.
WebAIM Million Annual Report Annual analysis of the top million websites' accessibility. Useful for understanding the most common failures across the web.