← Back to Work
Accessibility2023-2026

Component-level accessibility strategy

Bringing ~300 pages of client web properties to WCAG 2.1 AA under EAA and ADA exposure, by tracing every violation to its origin: component code, global styles, third-party embeds, platform updates, or content entry.

RoleAccessibility strategy & remediation
Year2023-2026
Toolsaxe-core, Pa11y, Playwright, Accessibility Insights, WCAG 2.1 AA

The problem: legal exposure at scale, and a fix that had to last

Between 2023-2026 I brought a set of client web properties, roughly 270-300 pages combined, to WCAG 2.1 AA. The work came out of redesign projects: these clients sell into markets covered by the European Accessibility Act and the Americans with Disabilities Act, where non-compliance means statutory fines, and a user lawsuit adds penalties and damages on top of them. So this was legal exposure, not polish.

There was a second requirement that ended up shaping the whole approach: conformance had to survive after I was gone. An audit that passes today and decays over the next two releases hasn't reduced anyone's legal risk. It has just moved the date.

How accessibility actually breaks on a live website

An a11y scanner tells you where a violation showed up. It doesn't tell you why it exists or why it will come back. On a site that multiple people, tools, and vendors keep changing, conformance is under pressure from directions that may have nothing to do with the page the defect appears on.

Background changes break the foreground. A theme refresh changes a background colour or a font stack, and every button and breadcrumb sitting on it quietly fails contrast. Nobody edited those elements, so nobody reviews them.

Third-party tools ship their own violations. Chat widgets, cookie banners, embedded catalogues, review carousels. Each one injects markup you don't control. They steal focus, trap the keyboard, and add unlabelled controls to pages that were clean the day before the script tag went in.

Platform updates wipe out fixes. On WordPress and similar platforms, a theme or plugin update regenerates markup and replaces template files. Any fix hardcoded into those files is gone, an ARIA attribute here, a corrected label there, and the changelog says minor improvements.

Many hands, no shared contract. Marketing uploads banners with no alt text. An editor pastes from a document and brings skipped heading levels with it. SEO rewrites headings for keywords. Sales clones an old template for a campaign page. Everyone is doing their job correctly, and every one of them is a way in for violations.

And fixes get applied where the defect was seen, not where it came from. Patch the instance, and the origin keeps producing the same defect everywhere else it renders. Element size, colors get fixed on the page someone visited and took notice. The gap persists on the remaining pages.

The common thread: Violations are symptoms. Every symptom has an origin, and remediation that doesn't trace it back to source isn't fixing the a11y for the site. It is competing with the scanner.

The method: Find the origin, fix the origin

Every finding, wherever it showed up, got classified into the layer that produced it and fixed there:

  1. Component code. The ~300 pages boiled down to about 65 reusable components, each mapped to the pages using it. Fix the component at source and every page using it is fixed. This inventory did most of the heavy lifting: thousands of findings became a list you can actually finish.
  2. Global styles. Contrast and typography failures were fixed at the token and stylesheet level, never element by element. Next time a background changes, it breaks in one place, visibly, instead of in three hundred, silently.
  3. Third-party embeds. A single point for approving third party embeds in the organisation. Configured to conform where the vendor allowed it, contained where they didn't, flagged for replacement where nothing worked.
  4. Platform and templates. The obvious choice is to fixes out of files that updates overwrite. But it is hard to track and introduces overhead. External overrides for such files which updates could not overwrite. Deployment & verification in mirrored staging environments before pushing the changes to production, so an update triggered verification instead of silent regression.
  5. Content entry. Missing alt text and broken heading order kept coming from everyday publishing, so the fix was rules for the people publishing. Everything goes through staging and verification of alt text and heading orders. Code cannot fix a defect that gets re-created in the CMS every week.

After that, one page-level pass for the things that only exist per page: document titles, landmark labels, page-specific content.

Durability came from the same map. It went into the ongoing workflow as the checklists for new work, so staying compliant depends on how work is done, instead of occurance of periodical audits.

Toolchain: Automation where it scales, people where it doesn't

No single tool covers WCAG 2.1 AA, so each tool got the layer it is actually good at.

axe-core did the automated scanning: scripted runs against components and rendered pages. Fast, repeatable, and consistent enough that before/after comparisons meant something.

Accessibility Insights ran its automated checks alongside axe-core, and its guided assessments structured the criteria automation can't judge, which kept manual review systematic instead of ad hoc.

Pa11y Used as the second opinion: on-demand runs against specific templates and flows to cross-check results.

Playwright for driving the states static scans never reach such as: open modals, expanded menus, focus traps, full keyboard paths, including through third-party surfaces like consent banners.

The point of the toolchain was to clear that half cheaply, so the human judgement was spent on the half that needed it: reading order, meaningful alternatives, and whether the site actually works with a keyboard and a screen reader.

Outcome

Both the engagements closed with WCAG 2.1 AA met across the audit. Two things mattered more than the sign-off.

The fixes persisted. Because fixes sat at the origin of its defect, the usual pattern, the same violations resurfacing release after release, didn't happen. Theme changes, content updates, and third-party tools stopped being silent regression channels; each one had a rule, an owner, or a checklist attached.

Methodology longevity. The origin map, the component inventory, and the content rules went into the regular workflow, so a11y became part of how new work gets built rather than a project that ended. That's the test I hold this work to: not whether the audit passed, but whether the next hundred pages shipped without the defects.