I audit, remediate, and build web systems to WCAG 2.2 AA, and I test them with the assistive technologies your users actually rely on — not just an automated scanner. A compliance badge and a usable experience are not the same thing, and the people affected can tell the difference.
Where most accessibility work goes wrong — and what I do instead.
Most accessibility problems share a common origin: the work was treated as a late-stage QA pass rather than a design consideration. Automated scanners can reliably catch perhaps a third of accessibility issues. The remaining two-thirds — focus management, reading order, semantic structure, error recovery, form usability, cognitive load — require a person who knows what to look for and has tested with real assistive technologies.
Across 15+ years of building web applications for healthcare and nonprofit clients, I’ve found that accessibility isn’t a checkbox to tick — it’s an approach that shapes design decisions from the first wireframe through deployment. Many users of the systems I’ve built rely on assistive technologies to access the services those platforms provide.
I build and remediate for people navigating with keyboards because of motor conditions, users listening through screen readers on slow connections, and individuals using browser zoom at 400% because default text is unreadable. WCAG 2.2 AA is the baseline, not the goal. The goal is that someone using your system can accomplish what they came to do — efficiently, independently, and with dignity.
A full audit of your site or application against WCAG 2.2 AA, combining automated tooling with manual review by someone who uses the assistive technologies involved. You receive a prioritized findings report, severity ratings, specific reproduction steps, and a remediation roadmap your team (or mine) can work through.
Implementation of the fixes identified in an audit — mine or someone else’s — with ongoing testing as I go. I prefer to remediate iteratively so you can verify each fix rather than receive a single opaque handover. Includes post-remediation re-test and updated conformance documentation.
New websites and web applications built to WCAG 2.2 AA from the start — semantic HTML, accessible components, keyboard-first interaction patterns, screen-reader verified at every milestone. Costs less over the lifetime of the system than retrofitting accessibility later, by a meaningful margin.
For organizations that have achieved conformance once and want to keep it that way. Regular review of new content and features, accessibility sign-off on releases, and staff training so your team can flag issues before they ship. Available as a retainer or as scheduled quarterly engagements.
What a real audit looks like, and why “automated only” isn’t enough.
Every audit begins with automated scanning — axe-core, WAVE, Lighthouse, and Pa11y — across a representative sample of page templates and application flows. This catches the issues that can be caught mechanically: missing alt attributes, empty form labels, obvious contrast failures, orphaned ARIA references. This typically surfaces 25–35% of the real issues on a site. Necessary, but nowhere near sufficient.
I then work through the site using only a keyboard. Every interactive element must be reachable, the focus order must match the visual order, focus must be visible at all times, and focus must return to sensible locations after modal dialogs, form errors, and navigation changes. A surprising number of “accessible” sites fail quietly here — the keyboard user gets lost, or trapped, or has to guess where focus went.
I test with the screen-reader / browser pairings real users actually use — NVDA with Firefox and Chrome on Windows, JAWS with Chrome on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. What reads correctly in one pairing can be mangled or silent in another. I document what I find and how to reproduce it.
Browser zoom at 200% and 400%, reflow at 320 CSS pixels, reading through content with forced colors mode (high-contrast), assessment of reading level and cognitive load on critical flows, and review of error messages and recovery paths — because someone who just hit a form validation error for the fifth time is the edge case that matters most.
Every issue is documented with: the specific WCAG 2.2 success criterion and severity, exact reproduction steps, a screenshot or recording, the affected user group, and a concrete recommended fix. I don’t hand over a 200-page PDF of machine output — I hand over a remediation plan your team can work through, prioritized by user impact and implementation effort.
A practical summary of the frameworks that may apply to your organization.
I’m a web practice, not a law firm, and nothing on this page constitutes legal advice. What follows is a practical summary of the standards most commonly relevant to clients I work with — your counsel is the right person to confirm which specifically apply to you.
| WCAG 2.2 (AA) | The technical standard for web accessibility, published by the W3C. My default working target for all engagements — both for conformance and for the actual usability it implies. |
|---|---|
| ADA (Title III) | Title III of the Americans with Disabilities Act applies to “places of public accommodation.” U.S. case law has increasingly treated websites and apps of covered entities as falling within Title III. Lawsuits and demand letters continue to trend upward year over year. |
| Section 508 | Applies to federal agencies and, commonly, to contractors and subcontractors delivering technology to them. Harmonized with WCAG 2.0 AA; many agencies expect 2.1 or 2.2 in practice. VPAT/ACR documentation is typically required. |
| State laws (U.S.) | A growing patchwork of state-level requirements, most notably around procurement and public-sector services. I track the most common ones I encounter and flag where they intersect with your engagement. |
If you’ve received an ADA-related demand letter or a serial-plaintiff complaint, I work with organizations in that position — discreetly, and in coordination with your legal team. The first priority is usually a fast, defensible audit and a documented remediation plan with real dates attached.
A typical audit-and-remediation engagement, week by week. Your timeline may vary with scope.
We confirm the pages and flows in scope, the technology stack, any known constraints (CMS limitations, third-party components), and the decision-makers on your side. You receive a fixed-fee proposal within a few business days.
Automated scanning, manual review, keyboard traversal, screen-reader testing across real pairings, cognitive and low-vision review. Documentation in progress throughout.
You receive the full audit report, the prioritized remediation roadmap, and an hour-long walkthrough call. The natural point to decide whether to engage me for remediation, bring it in-house, or stage the work over time.
Iterative remediation with weekly check-ins. I close issues as I resolve them so you can verify progress, rather than receiving a single opaque push at the end.
Full re-test, updated conformance documentation, accessibility statement draft, and — if relevant — a training session with your team so the work sticks after I leave.
WCAG 2.2 Level AA is my default target and what most current regulations expect. I can work against AAA for specific success criteria that matter for your audience, and I can work to WCAG 2.1 if your procurement context still requires it. I don’t recommend targeting Level A alone — it’s insufficient in nearly every jurisdiction now.
Yes. I produce VPAT 2.5 and Accessibility Conformance Reports against WCAG 2.2 and Section 508 as required. The work underlying these documents is a real audit rather than a self-declaration exercise — which matters both for honesty and for the situations in which a VPAT is scrutinized.
Yes. Automated scanners catch approximately a third of real accessibility issues. A perfect axe or WAVE score can coexist with serious keyboard traps, unlabeled form fields that screen readers can’t interpret, confusing focus order, and content that’s inaccessible at zoom. I’ve audited sites that scored cleanly on automated tools and had substantial real issues.
Yes, and I take that situation seriously. An expedited audit-and-roadmap engagement with a defensible timeline is usually the first priority — alongside coordination with your legal team. I can typically start within a few business days for this kind of work. Please reach out directly rather than through the general contact form and note the urgency.
Yes — and I recommend it, because accessibility is a practice, not a one-time project. I offer training sessions tailored to your team’s role (content authors, developers, designers, QA) and documentation your team can refer to after the engagement ends. The goal is that the site you ship after I’m gone continues to meet the standard.
Common and solvable. I can audit your design system or CMS component library separately, recommend which components need replacement versus patching, and often remediate at the component level so the fix propagates everywhere the component is used. Sometimes a partial re-platform is the right call — I’ll say so when that’s the case, rather than papering over it.
Audit, remediation, a new build, or help responding to a specific situation — a short conversation is the cleanest way to tell whether I’m the right fit.
Tell me briefly what you’re working on; I’ll come back within one business day.
I’ll send a short set of questions beforehand so the call is useful from the first minute.
