A website accessibility audit is a full test of a site against the Web Content Accessibility Guidelines (WCAG 2.1 AA, the standard the ADA now points to), covering every page, at two screen widths, by machine and by hand. It ends in a report that says exactly who is blocked, where, and what it takes to fix it. Champlin Enterprises now offers this as a standalone service: audit, remediation, and a before-and-after report you can hand to a lawyer, a board, or an auditor.

This post explains what a real audit involves, why the free scanner your marketing team ran does not count, and what the 2026 and 2027 ADA deadlines mean for organizations in Gurnee, Lake County, and everywhere else.

Who has to comply, and by when

Three rules now name WCAG 2.1 AA as the technical standard, and each one reaches a different kind of organization.

  • State and local government (ADA Title II). The Department of Justice rule published in April 2024 requires every city, county, school district, park district, library, and public college to make its web content and mobile apps conform to WCAG 2.1 AA. Entities serving 50,000 or more people had until April 24, 2026. Everyone smaller, including special districts, has until April 26, 2027.
  • Healthcare providers that take federal funding (Section 504). The HHS rule from May 2024 applies the same WCAG 2.1 AA standard to hospitals, clinics, and practices that receive HHS money, on a similar two-year timeline.
  • Private businesses (ADA Title III). There is no published technical standard for private sites yet, but courts and DOJ settlements consistently use WCAG as the yardstick. Thousands of federal web accessibility lawsuits are filed every year, most against retail, restaurant, hospitality, and professional-services sites, and a demand letter typically arrives before the lawsuit does.

For a public body in Lake County, the second deadline is seven months away as this is written. For a private business, the deadline is whenever a plaintiff’s firm runs a scanner over your site, which is exactly why the scanner is the wrong place to start.

A businesswoman who uses a wheelchair works on a laptop at a desk in a modern office
Accessibility is a question of whether real people can complete real tasks, not whether a scanner turns green. Photo by Marcus Aurelius on Pexels.

Why a scanner score is not an accessibility audit

Automated rule engines such as axe are excellent at what they can see: missing alt attributes, low-contrast text, form fields without labels, duplicate ids. They are also structurally blind to most of WCAG. A rule engine can reach roughly a third of the success criteria. The rest require a browser driven like a person.

Here is what that gap looks like in practice. On a recent 53-page government engagement, axe passed all 106 page-and-viewport combinations. Meanwhile a Level A blocker sat on the required application forms: the file upload could not be reached with a keyboard, so anyone using a screen reader or a switch device could not submit at all. Nothing automated found it. A script that actually tabbed through the form and pressed Enter did.

The failure runs the other direction too. Six separate “findings” on that same engagement turned out to be wrong, and acting on three of them would have made the site worse: one patch corrupted correct markup, another introduced a critical ARIA violation where there had been none. Every wrong finding came from measuring the wrong thing, such as reading a computed style when the browser only applies that rule on real keyboard focus.

The principle behind a defensible website accessibility audit is simple: a finding you have not measured the way a browser actually behaves is a hypothesis, not a defect. Suspect, measure, then fix, then measure again. When a number and a screenshot disagree, believe the screenshot.

Third-party scanner reports deserve the same scrutiny. A vendor tool scored one site 62% with “17 failed checks”; a full-rule engine run plus direct DOM probes of the exact categories it named found nothing in them. Two things to check about any such score: how much of it is Level AAA (often a fifth or more, and AAA is not required), and whether the tool is selling something. Many free checkers exist to generate leads for an overlay widget.

What a full website accessibility audit covers

An audit that will survive a lawyer’s reading has to test every page, both ways, and keep the evidence. This is the coverage we run.

Every page, from the CMS, not just the crawl

Crawling finds only what is linked. On that 53-page site the crawler found 45; the nine it missed were almost all forms (surveys, applications, a sign-in) because staff send those links directly rather than putting them in a menu. Forms are where people actually get blocked, so we merge the crawl with the CMS’s own page list and audit the union. Linked PDFs, uploaded HTML reports, and embedded dashboards count as pages too, and they are usually the least accessible thing on the site.

Automated pass at two widths

A full-rule axe run on every page at mobile (390px) and desktop widths, skipping server-error and security-plugin block pages rather than scoring them as failures.

What automation cannot see

  • Keyboard operation (2.1.1). Real tabbing through custom menus, modals, date pickers, uploaders. Does Enter actually open it?
  • Visible focus (2.4.7). Proven by screenshot diff while tabbing, not by reading a stylesheet.
  • Reflow at 320px (1.4.10). Tested by whether the page can genuinely scroll sideways, not by reading scrollWidth.
  • Text spacing, 200% zoom, target size, input purpose, new-window warnings.
  • Form errors and status messages (3.3.1, 3.3.3, 4.1.3). Are validation errors tied to their fields and announced?
  • Contrast over photographs (1.4.3). Sampled from the glyph pixels themselves, because hero text over an image has no single background color.
  • Markup validity. Duplicate ids, invalid ARIA, and bad nesting corrupt the accessibility tree before any rule engine looks at it.
  • WCAG 2.2 additions. A sticky header or cookie bar covering whatever you just tabbed to (2.4.11) is a layout fact, not a markup fault, and it is one of the most common failures on modern sites.
  • Documents. Which PDFs are actually linked from the site (usually far fewer than are sitting on the server), then real PDF/UA validation on that subset.
  • Media. Every video and audio element, so captions (1.2.2, Level A) get asked about, because uncaptioned video fails the site at Level A no matter how clean the HTML is.
Close-up of two hands typing on a black laptop keyboard
The single most revealing test: unplug the mouse and try to finish the form. Photo by Szabó Viktor on Pexels.

Fixing at the right layer

Auditing is read-only and always safe. Fixing is not, so we fix on a branch, a child theme, or a staging copy, one change at a time, and re-measure after each. Two of the fixes on the source engagement introduced new violations (an accessible name that no longer contained its visible label, and a banner that sat outside every landmark). Both were caught only because the audit was re-run.

Where a fix lives determines what it costs. In order of preference:

  1. A site-wide setting or a single media item. Alt text on the logo fixes every page at once.
  2. A theme-level stylesheet or script. One edit, survives plugin updates, covers every page.
  3. A plugin or platform setting. Supported, reversible, no code.
  4. Per-page content. The expensive one.

On the 53-page site, five of the six real defects were fixed at levels one and two. Only one needed a page edit. If a remediation plan is mostly level four, there is almost always a shared cause nobody has found yet. This is the same discipline we bring to SOC 2 evidence collection: fix the class of problem, keep the proof.

What you can honestly claim afterwards

Never write “100% compliant” or “fully WCAG compliant.” Conformance is not a certificate you pass; it is a claim you have to defend, and a single new page or one pasted table can break it. What a good report says instead:

Every WCAG 2.1 A and AA success criterion that can be verified from the website itself has been tested and passes, by automated and manual testing at two screen widths.

Then it names what remains outside that, plainly: captions that live inside the video platform, alt text that exists but may not describe the image well, documents that were remediated versus documents that were retired, and the fact that scripted browser testing is not the same as a session with a person who uses NVDA or VoiceOver every day.

The report also carries an accessibility statement you can publish immediately. For a public body facing a deadline, publishing the statement early demonstrates good faith while the remediation is still in progress.

Never install an accessibility overlay

If someone is selling you a one-line JavaScript widget that “makes your site ADA compliant,” decline. Overlays are rejected by the disability community and by accessibility practitioners: they do not deliver conformance, they routinely interfere with the screen readers and magnifiers people already use, and sites running them are still being sued. In January 2025 the FTC ordered one of the largest overlay vendors to pay $1 million over its compliance claims. For a public-sector client an overlay buys a false sense of compliance in place of real remediation. There is no shortcut through the markup.

How the Champlin Enterprises audit works

We have been engineering software since 1998, and we build websites and web applications for healthcare, nonprofits, and local government in the Gurnee and Lake County area and across Illinois. The accessibility audit grew out of that work, and it runs the same way for a site we built and a site we have never seen.

  1. Baseline. Full page inventory from the crawl plus your CMS, then every check above, with the raw output kept. Nothing changes until there is a “before.”
  2. Triage. Each finding is reproduced the way a user would hit it, assigned a level (A blocks people outright, AA is the legal target, AAA is optional and labelled as such), and assigned a fix layer.
  3. Remediation, with your permission. One change at a time, on a branch or staging copy, re-measured after each. We work in WordPress, Next.js, Laravel, and static sites, and we handle the platform traps (page builders storing escaped markup inside JSON, security plugins rate-limiting the scanner, CDN error pages being scored as failures).
  4. Verification and report. Everything from step one is re-run. The report opens with a plain-English summary any board member can read (“keyboard users could not submit your application forms”), and closes with a technical appendix an auditor can check, criterion by criterion, with measurements and screenshots.
  5. Staying compliant. Conformance decays as content is added. Sites on a care plan get the audit re-run on a schedule, so a new page or a pasted table is caught before a plaintiff catches it.

If you have a demand letter, a Title II deadline, or a scanner report you do not trust, talk to us. Audits are quoted on page count and complexity, and an audit-only engagement is always available if you have your own team to do the fixing.

Frequently asked questions

What is a website accessibility audit?

A website accessibility audit is a complete test of a site against WCAG 2.1 AA (and the 2.2 additions), using both automated rule engines and manual, browser-driven checks of keyboard operation, focus, reflow, forms, contrast, documents, and media. It produces a list of verified defects with their WCAG criterion, severity, and fix, plus an honest statement of what was and was not tested.

Is WCAG 2.1 AA or 2.2 AA the legal requirement?

The DOJ’s ADA Title II rule and the HHS Section 504 rule both name WCAG 2.1 AA. WCAG 2.2 AA is a superset, so a good audit reports against 2.2 where it costs nothing extra, but 2.1 AA is the binding target in the United States. Level AAA is never required.

How much of WCAG can an automated scanner check?

Roughly a third of the success criteria. Automated tools cannot tell whether a custom menu opens from the keyboard, whether focus is visible, whether a page really reflows at 320px, whether alt text is accurate, or whether a video is captioned. A clean scanner score on its own means very little.

How long does an accessibility audit take?

The baseline audit of a 50-page site takes a few days including manual checks. Remediation depends entirely on where the fixes live: a handful of theme-level changes can clear most of a site in a day, while per-page content fixes and PDF remediation scale with volume.

Does an accessibility overlay widget make a site ADA compliant?

No. Overlays do not produce WCAG conformance, they often break the assistive technology users already have, and sites running them continue to be sued. Regulators have also acted against overlay vendors’ compliance claims.

Do PDFs and documents count?

Yes. ADA Title II covers documents a public entity posts, with limited exceptions for archived and pre-existing content. The practical first step is separating the documents actually linked from the site from those merely sitting on the server, which is usually a much smaller job.