WCAG Accessibility Audits and Remediation
Meet WCAG 2.2 AA — the standard behind ADA web-accessibility expectations — with a real audit, hands-on remediation, and reporting that lowers legal risk and widens your audience.
ADA-related web-accessibility demand letters and lawsuits are common and rising, and most name small and mid-sized businesses that never thought their marketing site was a legal exposure. The letter usually arrives after an automated scanner flags an inaccessible page — no warning, a deadline, and a demand attached. The frustrating part is that the underlying problems are almost always ordinary markup issues that were cheap to prevent and are straightforward to fix.
The legal risk is only half of it. An inaccessible site also quietly locks out a real share of your audience — screen-reader users, keyboard-only users, people with low vision, colorblind visitors, and anyone with a motor impairment — who hit a wall and leave. And because search engines read a page much the way assistive technology does, the same defects that fail an audit also drag on your SEO. Fixing accessibility widens who can buy from you and strengthens how you get found at the same time.
The standard, and what an audit actually covers
The benchmark is WCAG 2.2 Level AA — the internationally recognized guideline that U.S. ADA expectations are measured against. In plain terms it means the site can be operated with a keyboard alone, read correctly by a screen reader, seen clearly at sufficient color contrast, and understood without relying on any single sense or a steady hand. A credible audit has to prove that, and no scanner can — automated tools catch perhaps a third of real issues, so I pair them with hands-on manual testing.
- Keyboard and focus: every control reachable and operable without a mouse, in a logical order, with a clearly visible focus indicator on each stop.
- Screen-reader passes: real testing with assistive technology such as NVDA and VoiceOver, checking that headings, landmarks, and ARIA announce the page correctly.
- Color, contrast, and motion: contrast ratios verified against AA, plus reduced-motion support and no content that flashes or moves in a way that excludes people.
- Forms and images: proper labels, error messages tied to their fields, meaningful alt text, and target sizes large enough to tap reliably.
- Structure and semantics: correct heading hierarchy, landmark regions, and ARIA used only where native HTML cannot do the job — never as a patch over broken markup.
Remediation, not just a report
Plenty of vendors will sell you a PDF of violations and leave the hard part on your desk. I do the hard part — I go into the code and fix it: semantic HTML in place of div soup, correct ARIA, contrast-safe colors, and real focus management. Then I re-test against the same WCAG 2.2 AA criteria and give you an accessibility statement and reporting you can actually show a customer, a partner, or opposing counsel. Accessibility is not a one-time checkbox — new content can regress it — so if you want that baseline held, my managed care plan folds these checks into ongoing upkeep.
One thing I will always tell you straight: an “accessibility overlay” widget is not compliance. Those one-line scripts do not fix the underlying markup, they frequently break the assistive technology they claim to help, and they have themselves drawn lawsuits. Real accessibility lives in the code, which is exactly the standards-driven, test-and-document work I came up on — five years of production infrastructure and security engineering, where auditing to a written benchmark and proving you met it is the whole job. The audit you get is rigorous, not a plugin scan.
Proof, and honest limits
This site is the proof: it is built to WCAG 2.2 AA, with a contrast-checked palette, full keyboard navigation, and reduced-motion awareness — the same standard I hold client work to. I am also careful with what I promise. Accessibility work meaningfully reduces legal risk and improves your compliance posture, but no honest engineer can guarantee legal immunity, and I will not pretend to give legal advice. What I can do is get your site to a defensible, documented AA baseline and keep it there.
If you have received a demand letter, or you just want to know where you stand before one arrives, send me the domain and a note on what you are worried about, and I will come back the same day with a fit assessment and either a quote or a referral.
Common questions
Do accessibility overlay widgets make my site compliant?
No. A one-line “accessibility overlay” script cannot fix inaccessible markup — it sits on top of the page and guesses. Overlays frequently break the very screen readers and keyboard tools they claim to help, and businesses that installed them have still received demand letters — some naming the overlay itself. Real accessibility is fixing the underlying HTML, ARIA, contrast, and focus behavior, which is what I do.
What is WCAG 2.2 Level AA, in plain terms?
WCAG is the international checklist for making web content usable by people with disabilities, and Level AA is the middle, practical tier that U.S. ADA expectations are generally measured against. In plain terms it means your site works with a keyboard alone, reads correctly in a screen reader, has enough color contrast, labels its forms, and does not rely on sight, hearing, or a steady hand to operate. That is the benchmark I audit and remediate to.
Is accessibility a one-time fix?
No — and I will not pretend otherwise. An audit and remediation get you to a clean, documented baseline, but new blog posts, images, PDFs, and layout changes can quietly regress it. If you want that baseline held over time, the managed care plan folds accessibility checks into ongoing upkeep; if you would rather own it yourself, I hand you the statement and the know-how to keep it there.
Have a project like this?
Tell me the environment, the timeline, and your constraints. I reply the same business day with a fit assessment and either a quote or a referral.