How to Perform an Accessibility Audit

Before you run a single test, decide what you are auditing and against which standard. A full audit of a large web application can take weeks if you try to cover every page. A focused audit of the most critical user journeys is more practical and still surfaces the most impactful issues.

Choose your compliance standard: WCAG 2.2 AA is the most widely required standard for web content. Section 508 is required for US federal procurement. EN 301 549 is the European equivalent. VPAT 2.5 covers all three in a single document.

Identify the pages to audit: at minimum, include the home page, login/registration, primary navigation paths, checkout or conversion flows, and any pages that handle user data.

Automated tools can catch roughly 30–40% of WCAG violations without any manual effort. They are fast, consistent, and excellent at finding issues like missing alt text, insufficient color contrast, missing form labels, and invalid ARIA usage.

The three most widely used automated tools are axe-core (the industry standard, used by most accessibility testing platforms), Pa11y (a command-line tool that wraps axe and HTML_CodeSniffer), and Google Lighthouse (built into Chrome DevTools, covers accessibility alongside performance and SEO).

Run automated tests on every page in your scope. Export the results and group violations by WCAG criterion. This gives you a baseline before manual testing begins.

Automated tools cannot test keyboard navigation. You must do this manually. Open your website and disconnect your mouse. Use only the Tab key to navigate forward, Shift+Tab to go backward, Enter to activate links and buttons, Space to toggle checkboxes and expand accordions, and arrow keys to navigate within components like menus and sliders.

Check that: every interactive element receives focus in a logical order, the focus indicator is clearly visible at all times, no keyboard traps exist (you can always Tab away from any component), modals trap focus correctly when open and release it when closed, and skip navigation links work correctly.

This is one of the most important parts of an accessibility audit. Keyboard accessibility is required by WCAG 2.1.1 and is fundamental to users who cannot use a mouse.

Screen reader testing reveals issues that neither automated tools nor keyboard testing can catch. The most common screen readers are NVDA (free, Windows), JAWS (paid, Windows), and VoiceOver (built into macOS and iOS).

Test the following: page titles are announced correctly when the page loads, headings create a logical document outline (use H1 for the main title, H2 for sections, etc.), images have meaningful alt text or are marked as decorative, form fields have associated labels that are announced when the field receives focus, error messages are announced when form validation fails, and dynamic content updates (like loading spinners or success messages) are announced via aria-live regions.

Pay special attention to custom interactive components like date pickers, carousels, and data tables. These are the most common sources of screen reader failures.

WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). WCAG 1.4.11 requires 3:1 for UI components and graphical objects.

Use a contrast checker tool to verify every text/background combination on your pages. Pay special attention to placeholder text in form fields (often fails), disabled button states, text on colored backgrounds, and text overlaid on images.

Also check that color is not the only means of conveying information (WCAG 1.4.1). For example, if a form field turns red to indicate an error, there must also be a text error message or icon.

Every violation you find should be documented with: the WCAG criterion it violates (e.g., 1.1.1 Non-text Content), the severity level (critical, serious, moderate, minor), the affected page URL, a description of the issue, the HTML source snippet, and remediation guidance.

If you need a VPAT, map each violation to the appropriate VPAT criterion and assign a conformance level (Supports, Partially Supports, Does Not Support, Not Applicable). Write remarks explaining the finding for each criterion.

ConformPilot automates this entire documentation process. It runs automated tests, maps violations to WCAG and VPAT criteria, and generates a complete Word document report in minutes.