Web

Accessibility Audits, With a Plan to Fix What We Find

A website accessibility audit service tests your site against the Web Content Accessibility Guidelines and then tells you, in plain language, which barriers stop real people from using it and exactly how to remove them. It is not an automated scan stapled to a PDF. It is manual testing with a keyboard and a screen reader, a tooling pass to catch what machines catch well, and a remediation plan your developers can act on without guessing.

We do this on the sites we build and improve, so the audit and the fixes live in the same codebase. That means findings turn into committed changes, not a backlog that sits untouched because nobody knows where to start or who owns which line of markup. When the audit and the remediation are the same engagement, there is no translation layer where fixes get lost between a report author and a development team who never saw the testing firsthand.

What an accessibility audit actually checks

The Web Content Accessibility Guidelines, currently version 2.2, organize accessibility around four ideas: content must be perceivable, operable, understandable, and robust. Conformance is measured at three levels, A, AA, and AAA. Most organizations target level AA, which is also the bar referenced by Americans with Disabilities Act case law, Section 508 in the United States, and EN 301 549 in Europe. A credible audit maps every finding to a specific success criterion at a specific level, so you know what you are measuring against instead of someone's opinion.

In practice, that means we test things like:

How the audit runs

Automated tools are fast and honest about a narrow slice of the problem. They catch missing alt attributes, obvious contrast failures, and broken label associations. They cannot tell you whether a focus order makes sense, whether an error message is actually helpful, or whether a custom dropdown works with a screen reader. Those answers require a human sitting with the page. So the audit runs in three layers.

Automated pass

We run an established engine such as axe across representative templates to reveal the machine-detectable issues quickly and consistently. This clears the easy volume so human time goes to the problems that matter. Automated checks are reliable for a specific set of things: missing alternative text, form fields with no programmatic label, duplicate element IDs, and text that falls below the minimum contrast ratio. Running them first means the manual pass is not spent rediscovering problems a machine already flagged, and it gives us a consistent baseline to rerun after fixes so we can confirm nothing regressed.

Manual keyboard and assistive technology testing

We work through each key page and interaction with the keyboard alone, then again with a screen reader. This is where the real barriers emerge: a carousel that traps focus, a menu that cannot be opened without a mouse, a confirmation that is announced to sighted users and stays silent for everyone else. We also check that focus is never lost behind an open menu or modal, that the visible focus ring is actually present on every interactive element, and that content revealed on interaction is announced rather than silently inserted into the page. None of those are things a scanner can see.

Template and component coverage

A marketing site is not hundreds of unique pages. It is a set of templates and components repeated across many URLs. We audit each template and shared component once, which covers the whole site without pretending to hand-inspect every page. New issues get caught where they are actually introduced, in the component, which is also where a single fix repairs them everywhere at once.

What you receive

The deliverable is built to be used, not filed. You get a findings report that lists each issue, the exact WCAG success criterion it violates, where it occurs on the site, a severity rating based on how much it blocks a user, and a concrete instruction for fixing it. Severity is the part most reports get wrong. A decorative image missing alt text and a checkout button that cannot be reached by keyboard are not the same emergency, and the report treats them differently so your team spends effort in the right order.

Why overlays and widgets are not the answer

Accessibility overlay products promise a one-line script that makes a site compliant. They do not, and they cannot. An overlay sits on top of broken markup and tries to reinterpret it at runtime, which frequently makes the experience worse for the assistive technology users it claims to help. Real accessibility is a property of the HTML, the structure, and the interactions underneath. That is why an audit on a site we build is more useful than a plugin on a site we do not control: the fixes go into the source, where they hold through the next content update instead of being papered over on every page load.

Where this fits with the rest of the build

Accessibility overlaps with the work that makes a site fast and findable. Clean semantic structure helps screen readers and search crawlers alike. Proper headings, labeled controls, and well-described images serve both a person using a screen reader and the systems that index your content. If you are planning a redesign or a migration, the audit is best done as part of that work rather than after launch, when fixes are more expensive to retrofit into live code. Our ongoing SEO engagements run only on sites we build, and accessibility is part of the foundation that work stands on.

We do SEO on websites we build. That is the engagement this page sits inside.