Fix the component once, and every page that uses it improves.
We repair accessibility barriers where they start: in your components, templates, and content models. Fixes arrive as reviewed pull requests or theme changes, and we retest every one against the finding that prompted it.
Start with the components that repeat
An audit report can list hundreds of issues. Most of them trace back to a handful of shared components: an icon button with no accessible name, a modal that never moves focus, a product card whose whole surface is a click handler on a <div>. Fix those first and the count falls on every page that renders them.
So we begin with the component view from your audit. We rank each component by who it blocks and how many templates use it, then work down the list. A date picker that traps keyboard focus at checkout outranks a hundred decorative images with redundant alt text, even though the second number looks bigger in a spreadsheet.
Content follows the same logic. If editors keep uploading images without alt text, we make the field required in the CMS instead of fixing images one at a time forever.
We work in the stack you already have
The accessible patterns are the same everywhere. Where the fix lands depends on how your site is built.
| Platform | Where the fix lands | Typical first fixes |
|---|---|---|
| React and Next.js | Pull requests to your component library and app routes | Focus management after client-side navigation, names for icon buttons, aria-live regions for cart and form updates |
| Vue | Single-file components and router navigation hooks | Moving focus to the new heading after route changes, labeled custom selects, disclosure buttons with aria-expanded |
| Angular | Components and directives, using Angular CDK utilities such as cdkTrapFocus and LiveAnnouncer | Dialog focus traps, announced validation errors, keyboard support on custom menus |
| Shopify Liquid | A duplicate theme, previewed and reviewed before you publish it | Variant pickers, the cart drawer, product media alt text, and collection filters |
| WordPress | Theme templates, block patterns, and theme.json, or a replacement when a plugin can't be fixed | Navigation menus, form plugins, and editor patterns that keep heading order intact |
| Drupal | Twig templates, theme libraries, and module configuration | Views exposed filters, menu toggles, and editor rules that keep content structured |
| Headless CMS | Front-end components plus the content model itself | Required alt text fields, constrained heading levels in rich text, link text validation |
How a two-week sprint runs
Each sprint has a fixed scope, agreed on day one and drawn from your findings register.
Pick the sprint scope
We choose the findings that unblock the most people per hour of work, usually shared components and your critical journey. You approve the list before we start.
Fix in a branch
A developer on our team writes each fix in your repository or theme, following your conventions, linting, and tests. Every change references the finding it resolves.
Review twice
Your team reviews the code as usual. We review the behavior with a keyboard, zoom, and screen readers, and record it so reviewers can hear the before and after.
Retest against the original finding
After merge, an analyst retests each item exactly as the audit tested it and marks it resolved, partly resolved, or reopened in the register.
Hand off
You get a sprint report: what changed, what was retested, and what remains, with the evidence attached. The register stays yours.
Overlay widget vs source fix
An overlay widget
- Injects a script that tries to repair the page in the browser after it loads
- Leaves the broken component in your code, so every new page inherits the barrier
- Guesses at names and roles it has no way to verify
- Adds third-party JavaScript to every page view
A source fix
- Changes the component, template, or content model where the barrier starts
- Ships through your normal code review, tests, and deployment
- Works the same for every visitor, with or without assistive technology
- Leaves a pull request and a retest as evidence of what changed and when
We never install overlays
Overlays promise to fix a website with one line of JavaScript. The Federal Trade Commission's final order against one overlay vendor, accessiBe, requires the company to pay $1 million and bars it from claiming, without supporting evidence, that its automated product can make any website conform to WCAG. If you already run an overlay, we'll help you remove it as part of remediation, because it can interfere with the fixes we make.
Your developers keep the knowledge
Some teams want fixes delivered and nothing else. Others want to come out of the engagement able to build accessible components without us. We do both.
In pairing mode, a developer on our team works alongside yours: shared branches, short screen-reader demos during code review, and comments that explain the pattern, not just the patch. After a sprint or two, your developers write the fixes and we review them.
When something can't be fixed in your code, such as a third-party chat widget or a payment iframe, we contain what we can, document the rest with evidence, and draft the request your vendor manager can send.
Priced by the sprint
Remediation sprint
Starting at
$6,500per two-week sprint
Fixes delivered as reviewed pull requests or theme changes, then retested against the original findings.
Request a quoteThe number of sprints depends mostly on how many shared components are involved. We estimate it from your findings register before you commit to anything.
What development teams ask us
Can you fix issues from an audit another firm did?
Yes. We retest a sample of the findings first, because reports vary in accuracy, then plan sprints from the confirmed list. If something important is missing, we tell you before we start.
Will you follow our code conventions and CI?
Yes. We work in your branches, pass your linting and tests, and submit through your normal pull request process. If you like, we add automated accessibility checks to your pipeline as we go; see Accessible Development & Training.
What about barriers inside third-party widgets?
We can't change a vendor's code, but we can often contain the problem: labeling an iframe, managing focus around an embed, or offering an accessible alternative path. For the rest, we document the barrier with evidence and draft the request for your vendor.
How do we stop fixed issues from coming back?
Retesting closes each finding, and Baclion Watch checks the same templates weekly afterward. Regressions arrive as tickets in your tracker, linked to the component and the original finding.
Can you fix performance problems in the same sprints?
Often, yes. Heavy components and unneeded scripts cause both barriers and slow interactions, so we flag the overlap and, if you've engaged us for Core Web Vitals, fix both in one pass.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.