Where your site actually fails, and what it takes to fix it

Most people who ask for an audit need one of two documents. A list engineers can work from, or something they can hand to a lawyer, a customer, or a procurement reviewer. A real audit is both, and it's written so neither reader has to translate it for the other.

The report is organized by issue and not by page. Forty screens sharing one broken date picker is one finding. Filing it forty times is how a report turns into noise nobody plans around. Each finding names the WCAG 2.2 success criterion it fails and the conformance level, says where it appears, describes what a person using a keyboard or a screen reader actually runs into, and gives a specific fix written for the engineer who has to make it. Screenshots and short screen recordings go in wherever the problem is faster to see than to read about.

Findings are ranked by what they cost a real user. Blockers come first, meaning anything that stops somebody from finishing a task at all. A checkout that can't be completed without a mouse is a different category of problem from a heading level that skips from h2 to h4, and a report that lists both in DOM order is easy to generate and useless to plan around.

We write down what's already working too. If your form errors are announced properly and your focus styles are visible, you need to know that before a redesign quietly throws it away. Teams lose good accessibility work all the time because nobody documented that it was there on purpose.

You also get a scope statement. Which pages, which flows, which browsers, which assistive technology, and what we didn't look at. An audit that doesn't say what it excluded is claiming more than it tested.

WCAG is the Web Content Accessibility Guidelines, published by the W3C. Version 2.2 is the current recommendation. It's organized into success criteria at three levels: A, AA, and AAA.

Level AA is what almost everyone means when they say accessible. It's the level referenced by procurement requirements, by the European standard EN 301 549, and by most settlement agreements. Level A alone isn't enough for anyone serious. Level AAA isn't meant to be met across an entire site, and the W3C says so directly in the spec, so treat anyone selling you AAA conformance for a whole product with suspicion.

Conformance is measured per page and per process. That second part trips people up. If a checkout is five steps and step four fails, the whole flow fails, and you can't conform on the pages you like while a required step in the middle is broken. This is why we test flows end to end and not a sample of URLs.

WCAG 2.2 added criteria worth knowing about because they catch things older audits missed. Focus indicators can't be hidden behind sticky headers or cookie banners. Focus styling has minimum size and contrast requirements of its own. Anything you do by dragging needs a single-pointer alternative. Interactive targets have a minimum size of 24 by 24 CSS pixels at AA, with exceptions. Help links have to stay in a consistent place. Forms can't demand you retype information you already gave them in the same process. And authentication can't require a cognitive test like remembering or transcribing a code with no alternative path, which is the criterion that catches a lot of login flows people assumed were fine.

Here's the part we say out loud before anyone signs anything. Conformance is measurable. Legal risk isn't, and we don't indemnify it. We won't tell you an audit makes you ADA compliant, and we won't promise you can't be sued, because nobody honest can promise that. What we can do is test against a published standard, document what fails and what passes, help you fix it, and give you a dated record of the work. That record is worth a great deal. It just isn't a shield, and any vendor who tells you otherwise is selling you something they can't deliver.

Run axe or Lighthouse or Pa11y on your site right now. Do it before you call anybody. It's free, it takes a minute, and it'll catch real problems.

It'll also catch only a minority of the barriers that actually stop people. That's not a knock on the tools. It's what the tools are for. A scanner can tell you an image has no alt attribute. It can't tell you the alt text says image123.png, or that it describes the wrong thing, or that a decorative flourish got a paragraph of description that a screen reader user now has to sit through. It can tell you a button has no accessible name. It can't tell you the name says Click here on nine buttons that do nine different things.

The failures that ruin somebody's day are mostly the ones automation can't see. Focus that vanishes when a modal opens. A tab order that jumps around because the DOM order and the visual order stopped matching after a CSS grid refactor. An error message that turns red and never gets announced. A custom dropdown built out of divs that a scanner happily reports as clean because there's nothing there for it to complain about.

So we run the scanners first, because starting a manual review by hand-finding things a machine finds in seconds is a waste of your money. We clear the automated findings, then spend the real hours on the part that needs a person. Anyone quoting you an audit that's a scanner report with a cover page is charging you for a script you could have run yourself.

The keyboard test is the fastest honest signal you'll get about a site, and you can run it yourself this afternoon. Put the mouse down. Tab through the page.

Can you see where you are at every step? Can you reach every control, including the ones inside menus and modals and carousels? Does the order make sense against what's on screen? Can you open a dialog, do the thing, and get out again with Escape, with focus landing somewhere sensible instead of at the top of the document? Can you get stuck anywhere? If focus enters a widget and can't leave without a mouse, that's a keyboard trap, and it's a hard failure. Most sites break somewhere in the first two minutes of this.

Screen reader testing is slower and it's where the real findings come from. We test with NVDA on Windows in Firefox and Chrome, JAWS on Windows for the enterprise and government audiences that still standardize on it, and VoiceOver on macOS in Safari and on iOS. These aren't interchangeable. They disagree about ARIA, they announce the same markup differently, and something that reads perfectly in VoiceOver can be silent in JAWS. Testing one and calling it done is how you ship a bug to the exact users you were trying to help.

What we're listening for is whether the page makes sense with the screen turned off. Does the heading structure describe the page well enough to navigate by? Do landmarks let somebody skip past the nav on every single page instead of tabbing through it? When a form fails validation, does the user find out, and does focus go to the problem? When content loads without a page change, does anything say so, or does the page silently rearrange itself under a person who has no way to notice?

We record these sessions. A twenty second clip of a screen reader reading a broken form does more inside an engineering team than a paragraph in a spreadsheet ever will.

The same handful of failures show up over and over, across stacks, across teams, across budgets. If you want to know what an audit will find before you buy one, it's mostly this list.

Contrast. Placeholder text at a fashionable light grey, disabled states nobody checked, white text on a brand color that misses 4.5 to 1 by a hair, icons and form borders that miss the 3 to 1 requirement for interface components. This is the most common finding and the cheapest to fix, and it's a design system decision more than a code one.

Focus management. Opening a modal without moving focus into it, so a keyboard user is still tabbing through the page behind it. Closing it without sending focus back to what they came from. Removing outlines because they looked untidy in a mockup and never replacing them with anything.

Form labels. Placeholders used as labels, which disappear the moment somebody types. Labels not programmatically tied to their input. Required fields marked with a red asterisk and nothing else. Errors shown visually and never announced, or announced as a generic message that doesn't say which field is wrong.

Alt text. Missing on content images, present but meaningless, or written for decorative images that should be hidden from assistive technology entirely. Charts and infographics get the worst of it, since a real description of a chart belongs in text near the chart and not crammed into an attribute.

Heading order and structure. Multiple h1 elements, jumps from h2 to h5, headings chosen for their font size. Screen reader users navigate by heading constantly, so a broken outline removes the main way somebody moves through a long page.

ARIA misuse, which is our least favorite category because it's usually well intentioned. Roles applied to elements that already had the right semantics. aria-label overwriting a perfectly good visible name, which breaks voice control users who say what they see. States like aria-expanded that get set once and never updated. The first rule of ARIA in the spec is to not use ARIA when a native HTML element would do, and that rule is broken more than any other. A button element beats a div with role of button every time.

Motion and timing. Carousels that auto-advance with no pause. Parallax and animation that ignore the reduced motion preference the operating system is already sending you. Session timeouts and toasts that vanish before anyone using a screen reader has finished hearing them.

Somebody has probably pitched you a script tag that makes your site accessible. One line, install today, compliance handled. We think that's a bad purchase, and we'll say why instead of just saying no.

An overlay is JavaScript that loads after your page and tries to patch accessibility at runtime. Two things follow from that. It can only fix what it can detect, which is roughly the same narrow set a scanner detects, so it doesn't touch focus management, meaningful alt text, heading structure, or a custom widget with no semantics. And your underlying code stays broken, which means your conformance status doesn't change. WCAG conformance is evaluated against what the page delivers to assistive technology. A widget sitting on top doesn't rewrite the audit.

They can also make things worse. Overlays inject ARIA and reorder semantics in ways that conflict with what the user's own screen reader is already doing. Many ship a toolbar with font and contrast controls that duplicate features the operating system and browser already provide better. Screen reader users have said clearly and publicly that they don't want these, and some have to install browser extensions specifically to block them. Read what actual users of assistive technology write about overlays before you buy one. That's the research that should decide it.

The honest version of the pitch is that an overlay is a purchase made to feel protected. If a demand letter is what brought you here, an overlay doesn't fix the underlying barriers, and the barriers are what the complaint is about.

A report nobody acts on is a receipt. So the audit is the start of the work and not the whole of it.

How remediation runs depends on your team. Sometimes we hand over the findings and your engineers fix them, and we stay available for the questions that come up, because half of accessibility work is knowing which of three plausible fixes is the right one. Sometimes we work in your repository and submit pull requests through your normal review process. Often it's both, with us taking the gnarly custom components and your team taking the long tail of contrast and labels.

We fix causes and not instances wherever we can. If the same button component is wrong in sixty places, the fix goes in the component. If the contrast failures trace back to four color tokens, the fix goes in the tokens. Patching sixty call sites is slower, and it guarantees the sixty-first gets built wrong next month.

Then we retest. Every finding gets verified against the same standard and the same assistive technology, and you get an updated report showing what's closed, what's open, and what got introduced along the way, because remediation introduces regressions like any other code change does. Closing a finding on someone's say-so isn't verification.

Then comes the part that decides whether any of this lasts. Accessibility regresses by default, because the fix was a one-time cleanup and the pipeline that produced the problems never changed. So we wire automated checks into CI, where axe-core runs against your component tests and your key flows and fails the build on new violations. Not on the existing backlog, which would leave the build red forever and teach everyone to ignore it. On new violations only. We add keyboard and screen reader checks to the definition of done for the components that need them, and get accessibility acceptance criteria into the tickets where the design decisions actually get made. CI won't catch the interesting failures. What it does is stop the boring ones from piling back up between audits, which is what makes the next audit cheap.

If you're selling software to a federal agency, a university, a hospital system, or a large enterprise, someone is going to ask for a VPAT. Usually late, usually with a deadline attached, usually from a salesperson who just found out the deal depends on it.

A VPAT is the Voluntary Product Accessibility Template, a document format maintained by the Information Technology Industry Council. Filled in, it becomes an Accessibility Conformance Report. It walks through each applicable success criterion and records whether your product supports it, partially supports it, or doesn't support it, with remarks explaining the answer. It comes in editions: WCAG, Revised Section 508, EN 301 549, and an international edition covering all of them. Pick the one your buyer's checklist actually references.

Section 508 is the part of the Rehabilitation Act covering information and communication technology bought, developed, or used by federal agencies. The Revised 508 Standards incorporate WCAG Level A and AA by reference, which is why a 508 request and a WCAG AA request usually amount to the same testing work with a different cover sheet. There's also a 2024 Department of Justice rule under ADA Title II that sets WCAG 2.1 Level AA for state and local government web content and mobile apps, with compliance dates staggered by the size of the entity. If you sell to public agencies, that rule is why your buyers suddenly started asking.

The one thing that matters about a VPAT is that it has to be true. Partially Supports with a clear remark and a remediation date is a fine answer that closes deals. Supports written across every row because someone wanted the deal is a misrepresentation with your name on it, and buyers do test. We fill these out from actual test results, and where the answer is Does Not Support, we say so and attach what it would take to change.

Mobile apps get skipped, and then the procurement questionnaire asks about them. WCAG was written for web content, so it doesn't map perfectly onto a native app, but the criteria that matter translate cleanly and the platform vendors publish their own guidance on top.

On iOS we test with VoiceOver, and on Android with TalkBack. Both are on the device already, which means your engineers can reproduce every finding without buying anything. The recurring problems are their own flavor. Controls built from custom views with no accessibility label or trait, so the screen reader announces button and nothing else. Focus order that follows the view hierarchy instead of the visual layout. Touch targets under the platform minimum, which is where the WCAG 2.2 target size criterion and Apple and Google guidance all point the same direction. Layouts that break when someone turns on Dynamic Type or a large font scale, which is the single most used accessibility feature on either platform and the one most likely to shred an app that hardcoded its heights.

React Native, Flutter, and web views inside a shell each add their own gap between what you wrote and what the accessibility API receives. That gap is exactly where testing on a real device with the real screen reader earns its keep. The simulator lies.