How AI Does and Doesn’t Work for Accessibility

Blog: Solutions Review - Business Process Management

As part of Solutions Review’s Contributed Content Series—a collection of contributed articles written by our enterprise tech thought leader community—Navin Thadani, CEO and Co-Founder of Evinced, dives into how AI does (and sometimes doesn’t) work for accessibility.

You’ve read about it on this very site. Half of your team is talking about it. Most of them have toyed with it. Naturally, you’re curious: Can AI help you achieve your organization’s accessibility goals?

Today, when we talk about AI, we mean Generative AI and Language Learning Models (LLMs) such as ChatGPT. And with LLMs claiming to make your teams and their accessibility efforts more efficient, you’re probably wondering if using AI for accessibility is truly that easy. After all, couldn’t your engineering team use generative AI models to create accurate, accessible code? Wouldn’t it help to fill knowledge gaps or even, ultimately, replace headcount?

The answer is yes, but. Meaning LLMs are indeed a powerful tool for improving (and streamlining) accessibility, but only with the right approach.

Two Big Problems with AI for Accessibility

Wouldn’t it be a game-changer if your engineers could ask ChatGPT, “How should I code this element for maximum accessibility?” And get wholly accurate results every time? Yes, it would. But the technology isn’t there yet due to training bias and hallucinations.

Large Language Models are built on data; they must be trained on many examples (we’re talking in the billions) to yield the desired results. Current data shows that 96.3 percent of home pages have WCAG 2 failures. This means LMMs are trained on code that’s mostly inaccessible, resulting in a powerful training bias.

An even more challenging issue for Large Language Models is “hallucinations”—when an AI system gives you the wrong answer with complete confidence. Play around with ChatGPT or a similar program, and you’ll see what we mean. For example, we’ve asked it for simple things, like a list of movies by a particular director or books by a famous author, and the AI tool generated a list with nine out of 10 correct titles. That might sound good, but it’s still not good enough for the enterprise.

As UX engineer Kivi Shapiro once said, it’s essential to remember that “[ChatGPT] is a language model; it produces truthiness, not truth.”

Hallucinations don’t always happen, but they are frequent enough to make us not explicitly trust results from the AI programs currently on the market. Neither should you. We all want our products to be right all the time, not just some of the time.

How AI Can Work for Accessibility

When it comes to AI and accessibility, the goal is to use AI to suggest accessible code to a developer as they work. What’s more, it would be ideal if the code is specific to what they’re working on and, ultimately, to their company and even personal style. Will this reduce your headcount? Probably not. What it will do, however, is free up a truly significant amount of resources, making engineering teams happier and much faster. But to get to those benefits, AI has to be used correctly for accessibility, and any correct approach includes expertise, intent, and guardrails. Here is how it can be done.

Expertise

First, you will want to maintain an internal database that helps deliver deterministic answers free of hallucinations. You can then store your expertise about the kinds of elements developers are typically working on and make that expertise available using vector embedding.

Vector embedding is a standard technique for representing non-numerical items (words or sentences) as numbers. It’s used in Natural Language Processing (NLP) to aid efficient analysis and manipulation of text-based data.

Intent

Second, use AI to determine the developer’s intent at the point of their cursor. You will want to discover what ARIA pattern a developer is working on so you can, in effect, ask, “What kind of component are they trying to code up? A tab list, or something else?”

Identifying intent is critical because knowing what the developer is working on helps to understand how to code the element and its states and attributes. It is essential to know how the element is supposed to work on the page, how it should look, and how it should respond to user input and engagement.

Guardrails

Last, when you have a rough idea of the developer’s intent, you can ask the LMM for the right code once the ARIA pattern informs it. As an additional guardrail, the query to the AI system is extensively prompt-engineered, ensuring that it only returns code that passes an expertise check. The saying goes, “Everybody wants a revolution, but nobody wants to do the dishes.” With AI, in particular, the grunt work matters.

The Upside to Using AI

The hard truth is that if you have a team currently concerned about accessibility—which is great—it’s also true that they are almost certainly inefficient. That’s because internal accessibility resources are scarce. So, your teams are probably cycling back and forth between the resources you use for accessibility expertise and the code itself. Long wait times internally are common, and development gets stymied.

But here’s the upside: If you get AI right, you will increase efficiency and save money. There are claims that developers are 56 percent faster using AI-based tools. This is possible if those same tools deliver reliably accessible code completions. Then, you can realize the productivity benefits of AI that everybody wants.

Do you have a secret skunkworks project that you don’t have resources to staff? Now you do. Does the CEO say there will be a hiring freeze next year? No problem; you freed up your team to take on other tasks.

Using AI to help write accessible code is possible, but it requires accessibility expertise, understanding developer intent in real-time, and extensive prompt engineering. Ensure your approach has all three, and you’ll have a happier, more productive engineering team and a digitally accessible company.