AI Can Find the Failure. Who Decides What the Fix Should Be?

An engineer working on an accessible predictive search for a Shopify storefront found that AI can detect accessibility failures and propose fixes, but the fixes are not always correct. The AI suggested a Tab-key interaction for a combobox that contradicted the pattern, and proposed a uniform listbox for actions that required different interactions. The engineer emphasizes that detection is not judgment and that human expertise and user feedback remain essential in the remediation loop.

AI is changing accessibility remediation fast. It can find common accessibility failures, explain them, and increasingly write the fix. That's real, and it's useful. But finding a failure is not the same as deciding what the fix should be. The gap is easy to miss because it doesn't always produce an obviously wrong answer. Sometimes it produces a confident, plausible fix that is wrong for reasons that only become apparent when you understand the interaction in context. I recently worked through an accessible predictive search for a Shopify storefront with an AI assistant. A combobox with a listbox, screen-reader support, the usual. In places, it was genuinely good. It identified the right interaction pattern and the roles and interaction model it depends on. It reviewed the theme's existing JavaScript and caught real bugs, ones I'd have taken longer to find by hand. Keyboard navigation that didn't exist. An Escape handler that wiped the user's typed query. A live region toggled with aria-hidden instead of being left in the page, so it announced inconsistently across screen readers. That's detection working well. Then it started proposing fixes. It moved the search suggestions into a separate region, reached with the Tab key. Reasonable-looking. Also wrong. In a combobox, Tab moves focus out of the widget. A user navigating the suggestions with arrow keys shouldn't have to Tab into a separate region to reach them. The model had identified the right pattern and then proposed an interaction that contradicted it. I had to catch that. Another fix involved two different types of actions in the same listbox. Some options navigated to a product page and displayed the product image and name. Others rewrote the query and contained only the suggested query. Visually, the distinction was obvious. A sighted user could immediately tell a product result from a suggested query. But the interaction model wasn't. A listbox presents its children as options within a uniform selection model. When those options perform fundamentally different actions, the interaction model no longer matches what the options actually do. The better solution was to rethink the interaction rather than try to make the existing one more accessible. Again, the proposed fix was technically plausible. It just didn't survive contact with the actual interaction. Here's what made this risky. The wrong fixes arrived with exactly the same fluency and confidence as the right ones. Nothing in the response flagged "this one is probably wrong." If I hadn't understood how focus moves through a combobox, or thought carefully about what information actually reaches a screen-reader user through the accessibility tree, I could have shipped both. That's the real gap. The model had understood the visual UI, the ARIA pattern, and the relevant standards, but it hadn't reliably reasoned through what the resulting interaction communicated to the person using it. Detection is not judgment. Fluency is not judgment. The important part wasn't simply knowing the WCAG success criteria or looking up the relevant ARIA pattern. It was understanding how the interaction actually works for people using assistive technology. That understanding comes from accessibility expertise, testing, standards, technical experience, and importantly, lived experience. Not by pretending it's useless. It flagged real bugs, explained the standards, and drafted code faster than I would have. I'll keep using it for that. But AI should remain inside the remediation loop, not become the end of it. AI can detect. AI can explain. AI can propose. Engineers still need to evaluate the proposed solution in the context of the actual application. And disabled users still need to tell us whether the resulting experience actually works. The goal isn't to keep AI out of accessibility. It's to use it where it is strong without handing it the parts of the process that require judgment, context, and human experience. AI can often tell you what's broken. It can even suggest how to fix it. But it can't be the final authority on whether we've actually made the experience better for the people we're building it for.