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. The September 4 OpenAI Academy story about an accessibility specialist creating text-color controls makes that distinction concrete: personal adaptation and product repair are different deliverables.

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 elsewhere in the application.

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.

The transferable idea is specific: a person identified a barrier and used AI-assisted coding to make an adaptation. A site owner has a different responsibility in the engineering sense. The owner can change the source design and test the journeys affected by that change. Neither outcome should be described as the other.

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.

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.

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.

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.

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. The point is not to make a long generic checklist. It is to identify the states that share the changed styles and could plausibly regress. 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.

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. 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.

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.

The delivery note should name the component, the user problem, the tested states and any remaining uncertainty. For example, say that the field hint and error message were repaired and checked in both supported themes. Avoid saying the entire website is now accessible when the work covered one form.

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 business case for a small repair is straightforward: remove an observed barrier and preserve the improvement. It does not require an invented conversion lift or an assurance that AI has replaced specialist evaluation.