AI Accessibility Fixes Need More Than a Contrast Button

AI accessibility fixes should be judged by whether they remove a specific barrier for a person. A generated browser shortcut can be useful without proving that the underlying website is accessible, and a darker shade of grey in a screenshot proves even less. The September 4, 2026 OpenAI Academy account of an accessibility specialist building text-color controls with ChatGPT makes the distinction concrete: personal adaptation and product repair are different deliverables, and each supports a different claim.

For a founder using a coding agent to improve a website, the next step is to define the affected user task and verify the change in context. A screenshot of darker text is evidence about one visual state. It is not evidence about keyboard access, error recovery or whether the same fix works everywhere the component is used. This guide sets out how to brief the agent, which states to test, where generated fixes typically go wrong, and how to describe the result so the next person can trust it.

OpenAI Academy’s September 4 account describes James Warnken, an accessibility specialist with low vision, using ChatGPT to build browser tools that turn difficult-to-read text black or white. It is a first-party account of an individual’s use, not a controlled evaluation of accessibility outcomes or a certification of the sites being viewed.

Why does that matter for a business? Because the account is easy to read as “ChatGPT fixed accessibility”, and that reading leads a founder to the wrong brief. What the tool did was adapt pages for one reader, on that reader’s machine, under that reader’s control. Nothing changed for the next visitor. That is a legitimate and valuable result; it is simply a different deliverable from repairing the source, which is itself different from being able to say the site conforms to a standard.

The table separates the three. The middle column is the evidence each deliverable can honestly produce; the right column is the claim it cannot support. A team that keeps the rows apart stops over-claiming by accident.

Each row of the table ends in a sentence a team is entitled to write. “Our customer can now read the help text” is a claim about one person and one task. “The form’s hint text meets contrast in both themes” is a claim about a component. “The checkout can be completed by keyboard” is a claim about a journey. None of them is “the site is accessible”, and a coding agent will happily write that sentence in a pull-request description if nobody stops it.

An illustrative failure: a marketing site adds an AI-generated “high-contrast mode” toggle, announces improved accessibility, and a week later a visitor using a screen reader cannot submit the contact form because the error message is rendered as a color change with no text. The toggle was real. The claim was wrong, and the wrongness is now public. Scope the claim to the deliverable and this does not happen.

Replace “make the page accessible” with a report that names the problem. For example: the help text beside a form field is unreadable in a particular theme, and the error state makes it harder to identify which field needs attention. Capture the route, viewport, theme, state and intended action. Include the original component so the agent can repair the cause rather than paint over the symptom.

Keep the expected result equally concrete. The hint should remain legible, the label should remain associated with the field, and the error should be discoverable when navigation happens by keyboard. A small acceptance brief prevents the agent from substituting a global color override for a targeted repair, which is a common way these tasks go wrong.

Preserve user preferences where the application supports them. A change that improves one theme by breaking another creates a new task for the next person. Ask for the smallest coherent source change, then inspect every shared use of the component. If the agent cannot tell you where else the component is rendered, that is the first thing to find out, not the last.

WCAG 2.2 covers much more than contrast, including keyboard operation, focus and identifying errors. Use the relevant criteria to structure the test; do not infer whole-site conformance from one repaired component. The point of naming criteria is not to produce a long generic checklist. It is to identify the states that share the changed styles and could plausibly regress.

For a form repair, navigate without a pointer, submit incomplete information and locate the resulting error. Check the corrected state after entering valid data. Inspect zoom and a narrow viewport. If a dialog or menu appears, verify that the user can operate it and return to the previous task. For a reading repair, check selected text, links, visited links and text over images. Record which states were tested and keep the untested ones visible.

W3C’s evaluation overview states that tools alone cannot determine whether a site meets accessibility standards and that knowledgeable human evaluation is needed. A generated test suite is useful evidence, but it is not the whole evaluation, and an agent that reports “all accessibility tests pass” has told you about the tests, not the site.

The failure modes are predictable because they follow from how a coding agent reasons about a vague brief. Asked to “fix contrast”, it reaches for the broadest lever that makes the reported screenshot look right: a global rule, an inline override, or a brand-new stylesheet that wins by specificity. Each one passes the screenshot test and fails somewhere the screenshot did not look.

Four illustrative patterns to watch for. A global override that darkens all secondary text, including placeholder text that was deliberately lighter to read as a placeholder. A theme fix that hard-codes a color, so dark mode now shows near-black text on near-black background. A duplicate of the component with the fix applied, leaving the original in place for every other route. And a regression test that asserts the new hex value rather than the behavior, so the test passes while a later redesign reintroduces the barrier with a different color.

None of these is exotic, and all of them are caught by the checks in the previous section. The reason to name them is that an agent’s own summary will not. “Improved contrast on the billing form hint” describes every one of the four equally well.

Ask the affected person whether the repaired task is workable, if they are available and willing to participate. Their experience can expose problems that a developer would not notice, such as a hint that is now legible but reads in the wrong order, or an error that is announced before the field it refers to. Do not make that person responsible for approving every change or treat one user’s preference as universal.

Have a reviewer inspect the code and the user journey separately. A clean diff can still change the reading order or hide useful context. A visually convincing screenshot can still conceal a missing accessible name. Keep the original report attached to the review so the proposed fix is judged against the actual barrier, and give the two reviews different jobs so they do not inherit the same blind spot; our guide to independent review checks covers how.

Our WCAG audit reference provides the wider checklist. Agent-assisted landing-page QA covers the broader journey, while the browser rendering guide helps distinguish content from presentation defects.

In the delivery note, name the repaired component, the original barrier and the states tested. For the form example, record the hint and error checks in each supported theme, plus remaining uncertainty. A note that says “tested in dark theme at 390px and 1280px; light theme unchanged and not retested; screen-reader announcement not checked” is more useful than one that says “accessibility improved”, because the next person knows where to look.

This narrower description is useful for future maintenance. The next coding agent can see why the change exists and which behavior must survive a redesign. Add a regression check where it protects a real interaction, rather than generating a test that merely repeats the new CSS value. The same discipline applies when the agent publishes the change: our post on showing changes before publishing describes the review step, and teams building this into their delivery process can work with our AI transformation practice to make the note a required artifact rather than a habit.