AI accessibility audit finds routine controls blocking blind users

A missing button label can make an advanced AI tool unusable. In a September assessment of 30 products, a blind tester encountered hover-only controls, inaccessible outputs and responses that screen-reading software did not announce properly. Six products earned the publisher’s highest grade; eleven fell into its two lowest categories.[1]

AccessibilityChecker.org organised the assessment around ten everyday tasks performed with a screen reader and keyboard. It is a snapshot of one evaluator’s experience with the tested versions and configuration, rather than a formal accessibility certification. Its strongest contribution is the concrete account of where ordinary interactions broke down.[1]

An answer that cannot be retrieved is not an answer

The tasks followed a complete session: sign in, start a conversation, send a prompt, read and copy the response, stop or regenerate it, begin a new chat, reopen history, change a setting and sign out. A failure at any of those stages can prevent someone from independently using an otherwise capable system.[1]

One common failure involves controls that appear only on mouse hover. A sighted person moves a pointer over an image or message and sees 'copy' or 'download'. A keyboard user may have no equivalent action; a screen reader may not know that an actionable item exists. Another involves a button without an accessible label, which an assistive technology announces merely as 'button'. If the page has ten such controls, the user must guess at their function by experimentation.[1]

Dynamic AI answers add a newer problem. Responses appear incrementally, sometimes with tool statuses and interactive cards. Screen readers need meaningful announcements about those changes. If the interface silently replaces content, a blind user may not know that an answer has begun, ended or changed. Excessive announcements are bad too: a tool that reads every token aloud can make a long response functionally unusable.[1]

The study found relatively strong accessibility among several major general chat assistants. More failures arose in creative-image, video-generation, coding and agentic applications, where visual editors, custom canvases and mouse-first controls are common. The pattern makes design sense: rendering more powerful software capabilities often means inventing novel controls, and those controls can neglect established accessibility conventions.[1]

What the grades describe

A particularly revealing example concerns a coding tool where generated code was described as appearing blank to screen-reading software. The model may have produced valid code and the graphical editor may have displayed it correctly. Yet the person for whom that output was intended could not access the central result. That is a software product failure, not a defect in the model's reasoning engine.[1]

The grades combine time and effort, including workarounds and familiarity with an interface. The publisher explicitly says they are not a Web Content Accessibility Guidelines conformance audit. Browser, operating-system and screen-reader differences may change the experience, and products can fix or introduce barriers between releases.[1]

There is another disclosure to make: the organisation publishing the report sells accessibility testing and remediation services. That commercial position does not invalidate every observation, especially concrete demonstrations of inaccessible controls, but it is a reason to avoid treating the grades as an impartial universal ranking without independent replication.[1]

The simple engineering work that matters

Many of the necessary repairs are well understood. Every actionable component needs a meaningful programmatic name and role. Keyboard focus should move predictably. Status messages should arrive when the answer changes. A user must be able to stop a long response and copy or download the result without hunting for a hidden mouse action. A complex visual editor may need a structured text alternative, not merely a better colour palette.[1]

These improvements are not charity features appended after launch. They clarify a product's behaviour for everyone. A properly labelled 'Regenerate answer' button is easier to test automatically, easier to maintain across redesigned layouts and less confusing for people working with a phone or a keyboard. Good accessibility often exposes underlying engineering discipline.[1]

For AI developers, the report identifies a practical testing boundary: the task is not complete when a model generates its answer. It is complete when the user can find that answer, understand its status and use the result through the controls available to them.[1]

Report an error or suggest a correction