Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Accessibility Audit

What This Is

Before we can confirm that your website is usable by the broadest possible audience, and before we can responsibly recommend design, navigation, or content changes — we need to understand how your site currently performs for users who rely on assistive technologies, keyboard navigation, and structured content signals to experience the web.

The Accessibility Audit evaluates your site’s compliance with WCAG 2.1 AA — the Web Content Accessibility Guidelines that define the internationally recognized standard for accessible digital experiences. It examines your pages through automated testing to identify specific barriers that prevent users with disabilities from accessing content, completing tasks, or understanding page structure.

 

Why This Matters

Accessibility is not a compliance checkbox. It is a measure of how many people your website actually works for. An inaccessible site creates real barriers for users who are blind or low-vision, deaf or hard of hearing, have motor impairments, or rely on assistive technologies like screen readers and keyboard navigation. These are not edge-case users — approximately one in four adults in the United States lives with a disability that affects how they interact with digital products.

Beyond the user impact, accessibility failures create measurable business and legal risk. The volume of ADA-related website accessibility litigation has grown significantly year over year. Federal agencies, healthcare organizations, educational institutions, and many enterprise clients increasingly require documented WCAG compliance as a condition of doing business. A site with unresolved accessibility violations is a liability before, during, and after a redesign.

Common patterns we find across the sites we audit:

  • Images that convey information but have no alt text, making them completely invisible to screen readers and blocking comprehension for blind users.
  • Insufficient color contrast between foreground text and background, rendering content unreadable for users with low vision or color blindness — often on the very elements intended to drive action, like headlines and CTAs.
  • Interactive elements — buttons, links, modal close controls — that have no accessible name, leaving keyboard and screen reader users with no way to understand or operate them.
  • Page content structured visually with styled text rather than semantic HTML heading tags, removing the navigation shortcuts that screen reader users depend on to move through a page efficiently.
  • Scrollable regions, carousels, and interactive components that are inaccessible to keyboard-only users, placing large sections of content and functionality out of reach.
  • Landmark and structural errors that cause assistive technologies to skip content or navigate pages incorrectly.

These are not isolated technical problems. They are user experience failures that affect real people trying to accomplish real tasks on your site.

What We Examine

The Accessibility Audit evaluates every page tested across five primary dimensions, each corresponding to a category of WCAG 2.1 AA requirements.

Perceivability
Can users perceive all content on the page, regardless of how they experience it? This covers alternative text for images, captions for media, color contrast ratios, and whether information is conveyed through means other than color alone. Failures in this dimension mean content is invisible or meaningless to users who cannot see it the way it was designed to be seen.

Operability
Can users operate all interactive elements using only a keyboard, without requiring a mouse? This covers keyboard access to links, buttons, forms, carousels, modals, and scrollable regions. It also covers focus management — whether users can tell where they are on the page as they navigate. Failures here lock keyboard-only users and many assistive technology users out of core functionality.

Understandability
Can users understand the content and how to interact with the interface? This covers page language declaration, consistent navigation, clear labels on form inputs, and error messaging that tells users what went wrong and how to fix it. Failures here create confusion and prevent task completion.

Robustness
Is the site’s code structured in a way that assistive technologies can reliably interpret it? This covers semantic HTML, proper use of ARIA roles and attributes, valid markup, and correct implementation of interactive widget patterns. Failures here cause unpredictable behavior across different screen readers and browser combinations.

Structure and Navigation
Is the page organized with a logical, consistent heading hierarchy? Are landmark regions defined so users can jump directly to main content, navigation, and footer? Are page titles descriptive? Failures here force screen reader users to navigate pages linearly, without shortcuts, significantly increasing the time and effort required to find and use content.

 

How This Connects to the Broader Project

The Accessibility Audit is not a standalone compliance exercise. It is a direct input into the design, development, and content decisions made during a redesign.

It connects directly to:

  • Content strategy: heading structure, alt text, and semantic markup decisions made in the redesign need to be made correctly the first time. Retrofitting accessibility after launch is significantly more expensive than building it in from the start.
  • Design system: color choices, contrast ratios, and interactive component patterns must meet WCAG AA requirements. The audit identifies which current design decisions create barriers and where the redesign has room to fix them without compromising visual intent.
  • Development standards: the audit findings translate directly into a developer checklist for the build phase. Each finding includes a specific, implementable recommendation that can be verified before launch.
  • QA and launch readiness: the audit establishes a baseline. A post-launch re-test against the same pages confirms that accessibility issues were resolved and no new ones were introduced during the redesign.
  • Legal and compliance risk management: documented findings and documented remediation create a record of good-faith effort that is relevant in the event of an accessibility complaint or litigation.

 

You cannot build an accessible site without knowing what is broken first. The Accessibility Audit is where that understanding begins.

What You Get

The Accessibility Audit produces one deliverable.

An audit log provides every significant finding in a structured, concise format organized for both presentation use and developer implementation. Each row states the audit type, a plain-language finding, a specific actionable recommendation, and the impact level. Supporting columns include the issue group name, the pages and number of instances affected, a plain-language explanation of what the issue means for real users, and the applicable WCAG 2.1 AA criteria.

Findings are grouped by issue type rather than reported as individual axe violations, so a pattern that appears across multiple pages or elements is presented as a single finding with full context, not as dozens of disconnected rows. This structure is designed to feed directly into the master discovery audit log compiled across all audit types during the project, and to serve as a working reference for the developer or designer responsible for implementing the fixes.