Why can't "the screen looks clean" be used as the standard for judging accessibility?
Because visual presentation and underlying semantic structure are two separate layers — looking normal visually doesn't mean the underlying markup is correct. A button built with <div onClick> looks like an ordinary button on screen and clicks perfectly fine with a mouse, but a screen reader reads the underlying HTML semantic structure, not what's rendered on screen — that button effectively doesn't exist for a screen reader user.
This is also exactly why accessibility problems get overlooked so easily: checking with your eyes and operating with a mouse, the interface looks completely fine — the only way to actually catch the problem is switching to a different checking method: actually navigating through it with a keyboard, or listening through it with a screen reader. Visual inspection alone will never catch this class of problem.
AI-generated alt text being "technically accurate but functionally blind" — what does this mean concretely, can you walk through a fuller example?
Technically accurate means the description contains no factual errors; functionally blind means the description fails to convey what actually matters about the image in that specific context. For example, a product image on an e-commerce site shows "a red dress hanging on a rack." If AI-generated alt text only says "a red dress hanging on a rack," that sentence is entirely accurate, but it misses what a screen reader user actually needs in a shopping context — the dress's fabric, cut (fitted or loose), what occasion it suits — this is the information that actually determines whether to buy it, not the visual fact that "clothing is hanging on a rack."
This gap is hard to catch automatically because the W3C standard itself only requires that alt text "serve its intended function," without specifying what specific content alt text must include. Automated checkers can verify whether alt text exists, not whether that alt text captured what actually matters in context — that layer of judgment still requires manual intervention today.
"Automated tools catch only 30 to 40 percent of accessibility issues" — how should the remaining 60 to 70 percent actually be handled in practice?
The remaining 60 to 70 percent mostly falls into problems that only surface through actually experiencing the interface — the kind that can't be caught by scanning code or visual inspection alone, and require actually walking through the flow using assistive technology. Concretely, this means: navigating the entire interface from start to finish using only the keyboard (no mouse), confirming every interactive element can be focused via Tab, the order makes sense, and Esc closes popovers; using a free screen reader (NVDA on Windows, VoiceOver on Mac) paired with a browser to actually listen through the page content and confirm the reading order and information make sense.
These checks can't be fully automated because what needs to be judged is whether the experience makes sense, not whether it technically conforms to a spec — for example, focus management in a popover window might technically meet the specification, but actually operating it with a keyboard might reveal focus jumping around in a way that's still genuinely confusing. That kind of experience-level problem can only be caught by actually walking through it yourself.
If a team has limited resources and can't cover every check mentioned in this article, how should priorities be set?
With limited resources, it's worth prioritizing items with the broadest impact and lowest fix cost — semantic markup (<button> instead of <div onClick>) and color contrast are usually foundational work that gets set up once with a rule and applied consistently afterward, relatively controllable in cost, and directly affect the most basic usability (whether a link can be keyboard-focused, whether text is legible).
Keyboard navigation for complex interactions and live-region announcements, while equally important, usually need to be tested individually for each interactive component and carry a higher time cost — these can be handled once resources allow. For alt text quality, it's worth prioritizing a manual review at minimum for images that directly affect user decisions (product photos, infographics); decorative or secondary images can start with the AI-generated version and get reinforced gradually. The core priority logic is: first ensure basic usability (can it be operated, can it be seen), then address experience quality (is it pleasant to use, is the information complete enough).
AI-generated interfaces look clean and neatly laid out, which makes it easy to assume they're also accessible — this article addresses exactly that gap: the distance between an AI producing something that "looks good" visually and whether assistive technology users can actually use it is often significant, and the problem isn't limited to easily-checked things like color contrast.
For a screen reader user, a page isn't about what it looks like — it's about what it sounds like when read aloud, and what gets read aloud depends on the underlying semantic structure: buttons need to be `