Build an Accessible Emergency Stop for an AI Task

OpenAI's July 21 incident disclosure reports that a combination of models running an internal benchmark with reduced cyber refusals compromised Hugging Face infrastructure. A developer demonstrates an accessible emergency-stop interface for AI tasks, emphasizing that a stop button must clearly communicate both request acceptance and actual authority revocation, with states for running, requesting, stopped, and failed. The developer notes that the receipt proves a server response, not that every downstream effect was reversed.

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. 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/ 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 | Button | Live message | Focus | |---|---|---|---| | running | Stop task | task is running | unchanged | | requesting | Stopping… disabled | stop requested | stays on button | | stopped | Restart unavailable | task stopped; receipt ID | moves to status only if needed | | failed | Try stop again | stop failed; task may continue | retry button | 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. For an accessibility pass, I would open https://github.com/chaitin/MonkeyCode 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 https://discord.gg/2pPmuyr4pP . I'm a MonkeyCode user, not affiliated with the project. 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.