Can you be AI first and accessibility first?

Well? Can You?

I'd like the answer to be "yes," but the more I look at the evidence it seems AI first development has instead normalized lucrative mass discrimination.

What does accessibility first mean?

Simply put, a company considers users with disability needs at every phase of the product life cycle. Architecture, design, documentation and feature development incorporate WCAG (Web Content Accessibility Guideline) standards from the getgo. Nothing critical is sensory dependent.

Impossible to do with a developer-less LLM (language learning model) when its training data happens to include vindictively inaccessible code, but it hasn't stopped businesses from trying. 🤷

There are AI solutions that can genuinely help organizations remediate accessibility issues. Automated and manual accessibility defect detection tools can do wonders for teams. The potential to do better exists, but at present it's more profitable to degrade user experiences with a quantity over quality mentality.

To illustrate the regrettable state of the industry, we'll examine a small bit of code Google is serving to countless users every day. From a company that proudly claims 75% of its code is now AI generated, this is the standard users of assistive technology can expect in the immediate future.

I discovered this defect when looking up synonyms to use for character abilities in my hobbyist video game. Google's AI generated searches seem to use an odd mix of semantic HTML and <div> elements with aria roles. For example, this is what their main navigation element looks like:

Though the first rule of aria is don't use aria unless you have to, you can technically recreate the functionality of semantic HTML elements by jury-rigging <div> elements with aria roles and aria attributes.

Why would you do that to a <div> when you could use a <nav> instead? I'm not sure. There's no benefit to the user and you have a high likelihood of missing some native functionality of the semantic element. This isn't the defect though, merely a nitpick of the unnecessary and potentially disorienting aria role smatterings you'll commonly see in AI generated HTML.

The real issue comes from the markup of their lists, which incorrectly describe their actual number of items to users. For the word "bean," NVDA reads the first entry as List with three items clickable legume link.

Sure, there's three overall list items. But each list item should contain a child <ul> of five or six <li> elements. The sublist items were incorrectly wrapped in semantic-free <span> elements with <a> children elements. The parent <span> doesn't communicate meaning, role or the sublist item numbers to nonvisual users.

When I press Tab, my focus shifts to each sublist <a> element and tells me its name in a "list with three items." Five or six times. That's likely a confusing experience for a nonvisual user operating a screenreader.

This isn't a technically complex issue to fix. It's something a junior web developer learning HTML could do. And yet, it escaped Google's quality assurance process. If this is from the best in the industry championing AI first output, you should be highly suspicious of any vendor claiming they've fully automated accessibility.

What's the solve?

Well, using a LLM trained on robust, accessible code would help. I'm sure that's expensive though. Plus, the nondeterministic nature of the technology means expert review of its output isn't optional.

Hopefully more industry leaders start speaking out about this. Sadly, many of the AI enthusiasts I've chatted with on LinkedIn possess the moral compasses of recreational puppy punters. 🐶

One crypto bro told me that their keyboard nonfunctional, molasses slow website served all the users who matter. Unless legislation makes it more costly to not care about people, I fear we'll continue to see users with disability needs unceremoniously kicked off the internet by AI.