For engineering leads, developers and content teams

Most findings don't stall because they're hard. They stall because nobody owns them.

Every finding is routed to the person who can actually fix it — content editor, designer, developer or third-party vendor — and arrives in the tool that person already uses, with the fix attached.

Scan and see the split — freeSee who gets what

01 — The stall

Finding barriers is solved. Assigning them is not.

This is not our observation. It is what practitioners write down repeatedly when they describe why remediation programmes fail.

A ticket with no name on it

Practitioners are blunt about this: an issue assigned to "front-end" is an issue nobody feels responsible for, and issues get stuck when nobody knows who owns them. Assigning to a team is not assigning.

Accessible.org, remediation planning

Defects moving downstream

Where handoffs are undefined, editors blame the templates, developers blame content entry, legal gets a vague answer, and the risk stays open. The finding was never wrong. It just never landed anywhere.

ADA Compliance Pros, CMS accessibility

The template multiplier, backwards

One reusable component fix can clear hundreds of failures across an estate, while page-by-page cleanup rarely changes risk in a meaningful way. A flat list of findings hides which is which, so teams spend the sprint on the wrong end.

ADA Compliance Pros

02 — Routing

Four owners. Not two.

Splitting findings into "content" and "code" is closer than one flat list, but it still puts contrast failures on the wrong desk. Design owns a real category, and so does whoever manages your vendors.

  • Content editor

    Fixed in the CMS

    • Missing alt text on images
    • “Click here” link text
    • Heading levels skipped
    • Video without captions
    → Plain-language guide, per CMS. No selector, no jargon.
  • Designer

    Fixed in the design system

    • Colour contrast below threshold
    • Focus indicators too faint or absent
    • Targets smaller than 24 × 24 px
    • Meaning carried by colour alone
    → Measured ratio, failing pair, and a passing alternative.
  • Developer

    Fixed in source code

    • Focus traps in modal dialogs
    • A <code><div></code> acting as a button
    • Form controls with no label association
    • Dynamic updates never announced
    → Selector, criterion, before/after snippet, ticket export.
  • Vendor owner

    Fixed by somebody else

    • Chat widgets and support tools
    • Payment and booking iframes
    • Embedded video players and maps
    → Identified and attributed, so you can raise it in writing.

And a fifth column we label honestly rather than count as fixed: some findings — low contrast, small text, motion — can be worked around by a visitor using the widget. That is mitigation at the experience layer for the people who turn it on, not a repair. Those items stay open on the design or developer list until the underlying cause is fixed, and the report says so on the same line. A tool that closed them would be flattering its own dashboard.

03 — The fix

In your framework, not in prose.

The same finding as the ticket above, written four ways. Every snippet is tested against NVDA, JAWS and VoiceOver before it enters the library.

<!-- before -->
<div class="add-to-cart" onclick="addToCart()">Add to cart</div>

<!-- after -->
<button type="button" class="add-to-cart" onclick="addToCart()">
  Add to cart
</button>

Why the fix is usually smaller than the workaround

No role="button", no tabindex="0", no keydown handler for Enter and Space. The element that already does all of that ships with the browser. Most findings resolve this way, which is worth knowing before a team estimates an accessibility sprint at three times what it costs.

04 — Closure

A ticket closes when a re-scan says so.

Not when someone drags a card. The record keeps both dates: raised, and confirmed.

  • Re-scan after deploy

    Scan the changed pages against the baseline and see whether the finding is gone or merely moved. Scheduled scans cover this on any paid plan; scanning the moment a build lands needs the pipeline integration, which sits on the Infrastructure tier today.

    Mixed

  • Both dates stay in the record

    Raised on the 16th, confirmed closed on the 24th — eight days open. Time-to-close is the number worth reporting upward, because an average score can improve while nothing structural changes and time-to-close cannot.

    From free

  • What a re-scan cannot confirm

    It can confirm that a <code><button></code> is now a button. It cannot confirm that your new alt text describes the image, or that the checkout flow is completable with a screen reader. Practitioners generally recommend that a fix be re-tested by someone other than whoever made it — automation is not that someone.

    Manual audit

  • If you have no capacity, we can do the work

    On-demand expert remediation and remediation sprints are available where a team cannot take the tickets on. That is a service on the Infrastructure tier, not a button in the free plan, and we would rather you know which before you plan around it.

    Infrastructure

05 — Where we fit

We are not trying to beat axe in your IDE.

If you are a developer evaluating this page against the tool already in your editor, here is the honest comparison.

What the IDE-native tools do better

  • Catching the issue before the commit. A linter in the editor and a check in the pull request beat any post-deploy scan, ours included.
  • Depth of the rule engine and the knowledge base behind it. This category has a clear leader and it is not us.
  • Fixes offered inside the editor by an agent that can see your source tree. We scan rendered pages and give you a selector, not a line number.

What we are actually for

  • The people who are not in an IDE. A linter never reaches the marketing editor uploading images or the designer who owns the palette, and most findings on a content-heavy site belong to them.
  • The estate you did not build. Acquired brands, campaign microsites and templates from an agency that left — none of it is in your repository.
  • The record afterwards. Dated findings, dated closures and a report that states its own limits — the part a linter was never meant to produce.
  • Getting started without a purchase order. Scan and read the findings with no login and no card, which matters when the budget conversation has not happened yet.

If your whole estate is one repository and your whole team is engineers, buy the tool that lives in the editor and use our free scan as a second opinion. We would rather tell you that here than after an invoice. Most organisations are not that shape — they have a CMS, a design system, three agencies and a decade of pages nobody remembers publishing, and that is the situation this page is written for.

06 — FAQ

Questions, answered honestly.

Can the widget fix everything so developers never touch code?

No, and no tool on the market can honestly claim otherwise. The widget offers experience-layer controls — contrast, text size, spacing, motion — to visitors who turn them on. Meaningful alt text, captions, semantic markup and keyboard logic live in the source and in the CMS. We label which is which on every finding, and we do not mark widget-mitigated items as closed.

Which frameworks do the snippets cover?

Plain HTML, React, Vue and Angular today. Next.js and other React-based frameworks use the React guidance. If your stack is not on that list, the finding still arrives with the selector, the criterion and the HTML-level fix, which usually translates directly — and tell us what you are using, because the list grows in the order people ask.

How do non-technical people handle their findings?

Content findings are rewritten as plain-language steps for the platform the site actually runs on — WordPress, Shopify, Wix, Squarespace or Webflow — with no selector and no WCAG number in the instruction itself. An editor should be able to fix a missing alt text without learning what 1.1.1 means. The criterion is still recorded against the finding for the audit trail; it just is not what the editor reads.

Can we hear the screen reader difference, or only read it?

The simulator shows the announcement as text: you toggle between the broken and fixed markup and see exactly what a screen reader would say in each case, side by side. That is usually enough to end a debate in sprint planning. For the real thing, nothing replaces running NVDA or VoiceOver on the actual page, and our manual audits do exactly that on the flows where it matters — checkout, registration, account recovery.

We already use axe. Is there a reason to add this?

Sometimes not, and section 05 above says so plainly. Keep the editor tooling — it catches things earlier than we can. Add us where the work leaves engineering: content findings that belong to an editor in a CMS, contrast decisions that belong to a design system, third-party components that belong to a vendor manager, and the dated record that a linter was never designed to produce. If none of those apply to you, you probably do not need us.

Scan once. See who owns what.

Free, no login for the score and the issue list. The routing is visible before you create an account, because it is the part you are actually evaluating.

Scan and see the split — freeRemediation docs

For teams who would rather close ten tickets than open a hundred.