Code RoomAccessibility audit agent
EasyPrep Room Coding #21

Accessibility audit agent

Vibe & agenticAI agents & automationMid–Senior~13 min

Design an agent that audits accessibility on every UI change before merge. Be honest about the technology: which classes of accessibility problems can it genuinely catch, which require a human or a real assistive-technology user, and how should the agent communicate that boundary so a clean report isn't mistaken for 'fully accessible'? How would you measure whether it's actually improving outcomes, and how do you pitch it without overpromising?

Implement
route_accessibility_findings(findings: list[str], verified_fixed_rules: list[str]) → list[str]
Examples
in[["contrast=btn-primary","focus-order=modal","alt-text=hero-img"],["hero-img"]]out["advise","human","block","detected issues cover only mechanically checkable categories"]
in[[],[]]out["clean scan is not a claim of accessibility"]
in[["cognitive-load=checkout"],["checkout"]]out["human","clean scan is not a claim of accessibility"]
What a strong answer looks like

Turn the fuzzy goal into a bounded agent task. Say what the agent reads, what it may do on its own versus draft for a human, and what it must never touch. Then earn the trust: how you’d verify it before rollout, and the pitch (the problem, what you built, why it matters).

0:00 of about 13 min

Agent build: design the agent in plain language (or narrate it). The coach grades the decomposition, the guardrails, the verification plan, and the pitch.

Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.