There are a lot of good reasons to build accessible websites. It’s the right thing to do. It can help you avoid legal problems. Screen reader users make up a bigger portion of the population than many browsers that developers optimize for so there’s a business case. Heck, accessibility even helps improve how search engine crawlers can scrape and index the content on your website.
But, there is another reason to invest in accessibility even if none of the above reasons apply to you. Generative AI. Love it or hate it, generative AI is here to stay and it is already cannibalizing search traffic and recommending products. There are people who say that it is like blockchain or any of the other forgotten technologies and that’s possible, though I don’t recall Google taking up the top part of its search results page with Bitcoin price quotes or (for whatever reason) putting its index on a blockchain.
So, what if generative AI is here to stay? How will you structure your content in such a way that the generative AI models of tomorrow will know you exist and be able to tell people about you?
Web accessibility is the practice of making websites and applications usable for people who cannot rely on the default visual, mouse-driven version of the interface. For blind and visually impaired users, that often means translating visual structure, controls, order, and meaning into forms that screen readers and other assistive technology can understand. Much of the practice involves setting attributes and roles that can communicate what a control does, what information is important and what order it should be consumed in or what order tasks should be performed in. It is about expressing both content and the structure/function of that content in a non visual way.
The classic example of this are ARIA roles. It’s easy to get bogged down in a really deep definition and all the quirks of ARIA, but fundamentally ARIA roles and attributes are a way to provide context about an application to assistive technologies. ARIA roles will (or can) define what an element is, and ARIA attributes will (or can) define their state.
Why the ambiguity in my writing? I use screen readers a lot; they are a fundamental part of my development and testing workflow. Heck, I use them so much that I can almost use 40% of the web and occasionally even manage to accept a money transfer from my Dad with a screen reader. When ARIA roles and attributes are well implemented, they make using the web with a screen reader so much easier. When they are poorly implemented, it’s like being trapped in an Alfred Hitchcock movie.
And while there is increasing evidence that generative AI is using visual information to help contextualize documents, there is a simple economic reality at play here. Non visual information is a heck of a lot cheaper to collect and process. So generative AI companies will always have an interest in finding as much context in non visual ways as they can.
In other words, accessibility methods are a shortcut to teach the generative AI models of tomorrow about you and what you do. This isn’t to say that any of the ethical arguments are less valid. But the ethical arguments about accessibility don’t make the financial realities of building accessible applications any less valid. And so perhaps, if a company is on the fence about a major accessibility initiative, becoming more friendly for the artificial intelligence of tomorrow will push resources into accessibility.
Accessibility is still about people
The machine-readable benefits do not replace the human reason for accessibility. They add another practical reason to do work that already matters. Better structure, clearer controls, and more meaningful markup help people first.
However whatever your reasons for implementing accessibility technology, the fundamental purpose remains the same. Accessibility technology is about providing context and meaning to controls on a website. Whether that context and meaning is consumed by a blind or visually impaired user, a generative AI or a search engine, it performs roughly the same function and can provide roughly the same benefits if implemented properly.
We’ll get deeper into this in future resources.