You may have heard about the requirement in the U.S. for most state and local governments’ web content to be WCAG 2.1 AA compliant by April 26th. This is a big lift, and our librarians have already been fretting about it for months now. But as I go about poking at Aider and o3, I realize they can provide a helpful alternate window onto web accessibility.

You can use Aider to point o3 at a website or a codebase, and ask it to identify spots where it fails WCAG accessibility requirements. The feedback it gives is often helpful, but also often not correct. You should definitely know your code well in order to be able to tell if its suggestions are reasonable. And it is good to be wary of the fixes it supplies too. For example, o3 wanted me to go on a long, mulit-commit journey refactoring with flexbox, when adding { margin-top: 10px; } to an element was a perfectly acceptable solution.

To be clear, o3 is not a comprehensive accessibility solution. It will miss things and suggest things that are wrong. But I found that it also flagged a couple of problems that I hadn’t noticed, despite having looked at this code for (literally) years. It also had opinions on what to do about these problems, and those opinions were a useful starting point to figuring out some constructive changes.

The downside here, of course, is the possibility of putting too much faith in the LLM. Don’t do that. Know your code and how to fix it yourself. But aside from that, o3 may have some useful input.