Teaching an AI to fix the web without losing the human in the loop

Equally AI sells web accessibility to teams who mostly do not employ an accessibility expert. The product could already scan a site and list what was wrong. That was the problem. A scan on a mid-sized marketing site returned hundreds of violations written in the language of the specification — “element has insufficient colour contrast”, “ARIA attribute is not allowed” — and the person receiving that list was usually a marketer or a generalist developer with a compliance deadline.

Support tickets and the onboarding funnel told the same story from two directions: people signed up, ran a scan, and stalled. The business framing was activation. The design framing was different — the product was answering a question nobody had asked. Users did not want a list of everything wrong. They wanted to know what to do next, and whether it was safe to let the product do it for them.

I ran eleven interviews across three groups: accessibility specialists at agencies, in-house developers who had inherited compliance work, and marketing owners who bought the tool because of a legal notice. I paired that with the quantitative picture — where people dropped out of onboarding, which report screens got opened and abandoned, which issue types were most frequently marked resolved and then re-flagged on the next scan.

That quote reframed the project for me. The design problem was not accuracy — that was an engineering and model problem. The design problem was legibility of confidence.

We had been designing a report. We needed to design a working relationship. I wrote the reframe as a single line and used it to argue for scope in every review that followed:

That did real work. It killed the “auto-fix everything” button that had been on the roadmap. It justified spending interaction design effort on an explanation panel that a pure-efficiency view would have cut. And it gave the engineering team a rule for what the model had to expose: for every suggestion, a reason and a confidence level.

I prototyped all three in Figma at low fidelity and put them in front of six people from the original interview pool. Direction C won on a specific behaviour: participants started asking ARIA follow-up questions unprompted, which none of them did with the other two.

The file had to survive three parallel releases and hand-off to six engineers, so the structure was part of the design work, not admin.

Two rounds of usability testing, eight participants each, split between the personas. The first round broke in a way I did not expect: people trusted the AI too much. Confidence was rendered as a percentage, and participants read “87%” as a grade rather than a warning, applying low-confidence fixes without reading the diff.

I replaced the percentage with three named states — Confident, Worth a look, Needs your judgement — and made the lowest state require the diff to be expanded before the apply button became active. In round two, nobody applied an unreviewed low-confidence fix.

Beyond the number, the qualitative shift mattered more to the team: support conversations moved from “what does this list mean” to “can ARIA also handle this pattern”, which is the conversation you want to be having.