Creating accessible digital products is not just a legal requirement, it is good design. A web accessibility audit helps ensure that everyone, including users with access needs, can use your website or app with ease. It checks how well your product meets the Web Content Accessibility Guidelines (WCAG) 2.2, the global standard for inclusive digital experiences.
Understanding the Goal
The goal of an accessibility audit is simple: find and fix the barriers that stop people from perceiving, operating, or understanding your content. A proper audit looks at every part of your digital product, from design and content to code and user interactions.
An audit typically covers:
-
Design: color contrast, spacing, visual hierarchy.
-
Content: language clarity, heading structure, alt text.
-
Code and Semantics: HTML validity, ARIA roles.
- Interaction: keyboard navigation, focus order.
- Multimedia: captions, transcripts, playback controls.
So, first of all, start with a robust vision of wanted results.
Preparing for the Audit
Before starting, clearly define what you will test, such as specific pages, templates, or key user flows. Then identify which WCAG 2.2 criteria and level (A, AA, or AAA) apply. Set up your test environment with the latest browsers (Chrome, Firefox, Safari, Edge) and assistive technologies like NVDA, JAWS, and VoiceOver.
Make sure you can navigate with a keyboard alone.
Choose reliable tools such as axe DevTools, WAVE, and Lighthouse for automated scans, along with contrast analyzers and HTML validators. Testing mobile applications also requires platform-specific utilities: Google Accessibility Scanner for Android solutions and Xcode Accessibility Tools for iOS.
Finally, decide on your reporting format so each issue includes an ID, WCAG reference, description, severity, and recommended fix.
What to Check
Structure and Semantics
Your page structure sets the foundation for accessibility. Make sure headings follow a logical hierarchy, use proper landmarks (header, main, footer), and validate all HTML.
Only use ARIA roles when necessary and ensure lists, tables, and forms use semantic tags.
Text and Content
Good content helps everyone. Use clear page titles, descriptive link text, and accurate alt text for images.
Avoid placing text inside images and declare the correct page language to assist screen readers.
Visual Design
Test color contrast ratios (4.5:1 for normal text, 3:1 for large text) and ensure users can resize text up to 200% without breaking the layout.
Do not rely on color alone to show errors or states, and make sure focus indicators are visible and consistent.
Keyboard and Interaction
Every feature should work with a keyboard. Check that tab order follows a logical path and focus never gets trapped in modals.
Add "Skip to main content" links and ensure dynamic elements like menus or accordions communicate changes to assistive tech.
Forms and Inputs
Each input needs a visible, programmatically linked label. Provide examples or help text where needed, and make error messages clear and specific.
Validation should not depend on color and must work with screen readers.
Multimedia and Animations
Include captions for videos, transcripts for audio, and audio descriptions for key visuals. Users should be able to pause or stop motion and control autoplay.
Avoid flashing content and offer options to reduce or disable motion.
Navigation and Orientation
Keep navigation consistent across pages. Use breadcrumbs or sitemaps to help users stay oriented.
Menus should be accessible by both touch and keyboard, and links should look and behave the same everywhere.
Error Handling and Feedback
When users take an action, such as submitting a form, provide clear and accessible feedback.
Use ARIA live regions for real-time updates and summarize errors so screen readers can announce them.
For irreversible actions, add a confirmation or undo step.
Compatibility and Performance
Test your site on various browsers, devices, and assistive tools. Ensure pages load quickly and use progress indicators for long processes.
How to Test
A thorough audit combines several methods:
-
Automated Testing: run scans to find obvious issues.
-
Manual Expert Review: test keyboard navigation and screen reader output.
-
Assistive Technology Testing: perform real tasks using tools like NVDA or VoiceOver.
-
User Testing: observe users with disabilities in real scenarios.
-
Regression Testing: recheck important flows after fixes.
Make sure you’re applying all these methods effectively to achieve accurate, measurable results.
How to Report Issues
Organize your findings into a clear, comprehensive report. Ensure each section is properly structured and referenced. Include key metrics such as the total number of issues and highlight the most critical blockers. Specify the WCAG version, target conformance level, and details of the testing environment, including browsers and assistive technologies used. Aim to create a report that is both easy to understand and valuable for further action.
This is how your Web Accessibility Audit may look:
|
Section |
Component |
Purpose & Detail |
Audience Focus |
|
I. Executive Summary |
Overall Conformance Status |
Clear statement on whether the target WCAG level (e.g., AA) was met. |
Management |
|
Key Metrics & Severity Breakdown |
Total issues found, unique failures, and a visual representation of issue priority (Critical, Serious, Moderate). |
Management |
|
|
Top 3 High-Impact Issues |
Highlights the most severe defects that block essential user flows. |
Management |
|
|
High-Level Remediation Plan |
Initial guidance on the immediate next steps and prioritization. |
Management |
|
|
II. Scope & Methodology |
WCAG Standard & Level |
Explicitly states the version (e.g., WCAG 2.2) and the required conformance level (e.g., AA). |
All |
|
Tested Assets (Scope) |
Lists all specific URLs, templates, and key user flows included in the audit. |
All |
|
|
Test Environment Details |
Details the operating systems, browser versions, and screen resolutions used during testing. |
Technical |
|
|
Assistive Technologies Used |
Lists the screen readers and input devices used (e.g., NVDA, VoiceOver, Keyboard-only navigation). |
Technical |
|
|
III. Detailed Findings |
Unique Issue ID & Location |
A sequential tracking number and the exact page/component where the defect was found. |
Technical |
|
WCAG Success Criteria Reference |
The precise criteria that failed (e.g., 2.4.7 Focus Visible (AA)). |
Technical |
|
|
Severity & User Impact |
An assigned priority (Critical, Serious, etc.) and an explanation of who is affected and how. |
All |
|
|
Technical Description |
A detailed explanation of the defect, referencing code or structure. |
Technical |
|
|
Actionable Recommended Fix |
Clear, step-by-step instructions (with code snippets, if possible) on how to resolve the issue. |
Technical |
|
|
Visual Evidence (Screenshot/Video) |
Proof of the defect (especially useful for visual issues like contrast or focus). |
All |
|
|
IV. Review & Delivery |
No False Positives |
Confirmation that all reported issues are genuine defects and not tool errors. |
Technical |
|
Accessible Report Format |
Assurance that the report itself is delivered in an accessible format (e.g., tagged PDF). |
All |
Need Expert Support?
At UKAD, we combine technical expertise with a human approach to accessibility. Our QA specialists carry out WCAG 2.2 audits, guide remediation efforts, and help teams build ongoing accessibility monitoring.
We test your digital products with both automated tools and real assistive technologies so you get results that are practical and ready to act on.