Usable, accessible content: Is AI the new MVP?
By Stefan Nicolaou and Abigail B Vint
Content designers are responsible for usable, accessible content.
Wider access to AI and Large Language Models is posed as an existential question for content designers.
We wanted to explore how LLMs create content. Most importantly: how well do they do it and is the end result usable and accessible?
Is it time for content designers to put their feet up?
We get this question a lot: if AI and Large Language Models (LLMs) create content, will we still need content designers?
Let’s put it another way:
Now we have Google Translate, do we still need foreign language teachers?
Well, if I wanted to ask after someone’s wellbeing in English. I might say:
“How are you?”
“Alright mate?”
“How’re you holding up?”
“What’s wrong???”
“What’s been going on with you lately…”
The ‘correct’ translation depends on context:
- who you’re talking to
- how they’re feeling
- what kind of answer you’re trying to get
- previous knowledge and experience
Content designers work in the same way. We understand context based on evidence and experience.
Large Language Models do not.
LLMs are closer to Pez dispensers than humans
Content designers write for specific users in specific situations. We consider data, empathy and research to judge whether a content meets a specific person’s need.
LLMs outputs are statistical responses, not considered ones.
We give them prompts and LLMs use digital content (‘training data’) to predict what comes next.
Much in the same way your phone’s autocomplete will suggest you finish ‘he’ with ‘hello’ instead of ‘helter skelter.’
Unless you really love slides.
LLMs only perform well if they have well-structured prompts and curated training data.
They are:
- prone to inaccuracies
- don’t have access to insight from real users
- tone-deaf
- limited to broad, existing public information
Content designers are constantly building and re-contextualizing knowledge in real life situations.
Our tools, not our leaders
We’re already using tools that use machine learning to help us as we work. Grammarly and Hemingway use their training data to suggest how text could be simplified and easier to read. In this case the training data is rules about sentence structure, active and passive voice and sentence and word complexity.
Accessibility and usability has rigid rules…as well as all that skilled, data-led design
LLMs are best used when they are doing formulaic, easy-to-predict tasks. They need structure and rules.
This led us to wonder whether we could use accessibility and usability standards as training data.
Standards is just another word for rules, after all.
Our experiment
We wrote code which had accessibility issues such as:
- Unclear error messages
- Link text not describing the link destination
- Page titles not updating to reflect a change of state on a page
Error messages
According to GOV.UK design system error messages must:
- directly include language from the question or fieldset label
- describe what has happened and how to fix it
Our examples code did not meet either of these requirements.
It doesn’t tell users which field has a problem, what went wrong, or how to fix it:
Our LLM system gave us the following verdict.
It identifies, correctly, that the error message should:
- include the field title
- describe what’s wrong
This is pretty impressive.
However it also suggests an error message: “Full name is incorrect or incomplete.” This is an improvement, but in a real service we’d want to describe in more detail and in friendlier language what the problem is and how to fix it.
Link text
The purpose of each link must be determined from the link text alone to meet can WCAG accessibility criteria.
We gave it the link text ‘click here’, which doesn’t describe what happens when a user selects it or why they might want to use it.
Our LLM tool correctly identified that this wasn’t a usable, accessible link. Instead it suggested:
“Search on Google,” which is pretty close to what we’d use to describe a link that sends users to Google.co.uk
Marking up code
Accessible content is about how we use words.
Another crucial element is how those words are written in code.
For example, a sighted user will see an error message. If we use ARIA tags in the underlying code, this means assistive technologies (and their users) will ‘see’ them too.
This can be easy to overlook in product development, especially if designers and developers assume the other will do it.
Our LLM experiment suggested, in the example of error messages, to include ARIA tags in code. It even explained that this this would ‘help users who rely on assistive technologies to understand the error and how to correct it.’
Content design apocalypse, not now-ish
LLMs could help us learn accessibility as we design. They could serve as our assistants or ‘utility workers’:
- identifying usability issues
- suggesting code mark up
- drafting microcopy
- integrate accessible designing into our work
The ‘But’
Absolutely there is an opportunity to use these systems to be more efficient or to learn best practice as we go.
But.
There is a lot of upfront work to produce something a human still needs to verify and improve. The examples included in this post required hours of:
- incremental adjustments and rewrites of code and prompts
- analyzing and comparing how prompt variations affected output
- developer support using Python, Terminal and Visual Studio Code
The orange-paint bit
It’s also important to remember the amount of natural resources being used by LLMs.
As Kate Crawford writes in Nature magazine, assessments suggest Chat GPT is already consuming the energy of 33,000 homes. The demand for water for AI could be half that of the United Kingdom by 2027.
We must put AI to work for genuine efficiency, not just for the sake of using high end technology…or paying for fewer content designers….
