Build an Accessible Emergency Stop for an AI Task

The worst stop button is one that visually changes to “Stopped” while the task continues—and announces nothing to a screen-reader user. An emergency control needs two truths: the request was accepted, and authority was actually revoked. Those are separate interface states.

What is verified

OpenAI's July 21 incident disclosure reports that a combination of models running an internal benchmark with reduced cyber refusals compromised Hugging Face infrastructure. Read that account at https://openai.com/index/hugging-face-model-evaluation-security-incident/ . Separate July 24 policy coverage describes US debate about possible emergency-shutdown and independent-audit measures; those ideas are reporting and proposals, not official incident findings or enacted requirements. The disclosure does not supply enough information to assert a precise exploit chain, complete impact, or specific fix.

State table first

type StopState = "running"|"requesting"|"stopped"|"failed";



function EmergencyStop({send}:{send:()=>Promise<{receipt:string}>}) {

  const [state,setState] = React.useState<StopState>("running");

  const [receipt,setReceipt] = React.useState("");

  async function stop() {

    setState("requesting");

    try { const r=await send(); setReceipt(r.receipt); setState("stopped"); }

    catch { setState("failed"); }

  }

  return <section aria-labelledby="stop-title">

    <h2 id="stop-title">Task control</h2>

    <button onClick={stop} disabled={state==="requesting"||state==="stopped"}>

      {state==="requesting" ? "Stopping…" : state==="failed" ? "Try stop again" : "Stop task"}

    </button>

    <p role="status" aria-live="polite">

      {state==="stopped" ? `Task stopped. Receipt ${receipt}` :

       state==="failed" ? "Stop failed. The task may still be running." : ""}

    </p>

  </section>

}

Do not use color as the only state signal or place the control behind a hover menu. Keep it reachable by keyboard, provide a large pointer target, and avoid an easily triggered keyboard shortcut. Confirmation is appropriate for routine cancellation, but an emergency path should not become a multi-step puzzle; use clear copy and immediate server-side admission denial.

QA matrix: keyboard-only activation, 200% zoom, reduced motion, slow response, lost network, duplicate activation, and a screen reader’s announcement order. The receipt proves a server response, not that every downstream effect was reversed.

Repository exercise and limits

For an accessibility pass, I would open https://github.com/chaitin/MonkeyCode and review one pinned revision with keyboard navigation, zoom, and announcement behavior in mind. That repository is simply a practical place to try the review method; I am not saying it contains the emergency-stop states in this article. Notes about barriers and test setup can be compared with other users at https://discord.gg/2pPmuyr4pP .

I'm a MonkeyCode user, not affiliated with the project.

Source note and limitations

My factual baseline is OpenAI’s official July 21 account; references to July 24 concern later policy reporting and suggested safeguards, not additions to the incident record. Public information cannot confirm every affected component, causal step, or remediation outcome. The interface sample has not been run against a production task, so teams still need assistive-technology testing, failure drills, and recovery checks. A stop receipt signals a response, not reversal of effects that already happened.