Jump To

Project overview

Planning

Findings

Results

Accessibility and Inclusive Design

Accessibility audit slides, inclusive persona cards, and workshop artefacts used to identify barriers and educate teams

Turning low-priority legacy digital experiences into a catalyst for inclusive design change.

No time to read the full case study?

I conducted an accessibility audit of a legacy service, using inclusive personas and assistive technology testing to uncover usability barriers. By translating WCAG issues into human stories, I helped stakeholders understand the impact and sparked wider internal conversations about accessibility.

90+ issues identified
100+ internal requests
Workshop for 30 colleagues

Backstory

During a quieter period at work, my manager asked me to investigate one of our legacy services and identify opportunities for improvement.

The service was a contact form attached to our public website. It was aimed at users of our legacy software and had very low traffic, so appetite for improvement was low.

I had no specific brief to work to, simply familiarise myself with the service and develop a proposal of what I would tackle first if given the chance.

I chose to make personas a central theme of this project so I could stay accountable to a broad range of user needs.

Planning

Testing plan

Methods

Heuristic evaluation to get a baseline of the experience
screen reader testing
"No mouse" keyboard testing
Mobile phone testing

Testing goals

Understand what support topics are available
Complete a "Change my personal details" request
Complete a "Nomination of beneficiaries" request

Inclusive personas

Assumed Sam

Sam has no perceived accessibility needs, and accesses the platform from her home computer, equipped with a keyboard, mouse and high-speed internet connection.

Understanding our assumed user

Our assumed user is thought to face no barriers in how they access our products. They are thought to be in good health, neurotypical, able-bodied, and have access to a good-quality computer and high-speed internet. We also assume they have set aside time to complete their tasks and will not face any external disturbances. These assumptions allow them the use of a mouse and keyboard.

Key needs

An intuitive, well-designed user experience Logical instructions and forms to complete desired actions quickly and efficiently
Signposting to any further actions required

Visually Impaired Sam

Sam has poorly managed diabetes which has caused diabetic retinopathy and is now registered legally blind. He uses a screen reader to help him get about the web.

Understanding visually impaired users

Visually impaired users are individuals who have difficulty seeing or are completely blind. There is more to vision impairment than the amount visible, users may have a form of colour blindness, lose their glasses, or be in an environment with harsh lighting conditions causing screen glare. Depending on the severity of the impairment, various assistive technologies can be employed such as screen readers, magnifiers, and braille displays.

Key needs

Scalable content that works with magnification
Alternative text to audibly capture the on-screen experience
Access to skip links to quickly complete web actions

Motor Impaired Sam

Sam was recently diagnosed with Parkinson's disease after noticing persistent tremors, especially in her hands. She has been trying navigating the web using her keyboard as she finds a mouse too tricky to use precisely.

Understanding motor impaired users

Users can have a varying degree of mobility, which may cause issues typing, scrolling, clicking, or aiming a mouse. Motor impairments can stem from chronic conditions or disability such as paralysis or tremor disorders, as well as temporary restrictions such as a fractured wrist or multitasking. Assistive technologies that allow alternative inputs include speech recognition software, specialised keyboards, and eye-tracking devices.

Key needs

Visible, obvious focus states highlighting where the user is within the page
Forgiveness and ability to correct mis-clicks
Interactive content must accept input from alternatives input devices

Neurodiverse Sam

Sam is autistic, and while it generally doesn't limit them, they find tasks with vague instructions infuriating and like to have all the information possible.

Understanding neurodiverse users

Neurodivergent web users are individuals with neurological differences that affect their ability to process information and interact with the world around them. These users may have conditions such as autism, ADHD, dyslexia, or other cognitive differences, and there is a large variety of support needs within conditions. They may have difficulty processing information quickly, understanding complex language, or focusing for long periods of time.

Key needs

Clear, easy to understand instructions
Simple interface with well-labeled CTAs and minimal clutter
Support on how to independently complete tasks and correct any errors that occur

Mobile Phone Sam

Sam spilled water on her computer a few months ago and hasn't been able to afford a replacement, so has been getting by using just her phone.

Understanding mobile phone users

Using a mobile phone is not by any means an impairment. However, users accessing us via mobile devices require additional considerations, such as how design scales and how much content is visible at a time. Using the web on a mobile device opens up new ways to interact with the content, thinking about scrolling, pinching and tapping. Depending on the environment they're using their phone in, they may also fall temporarily under other accessibility categories.

Key needs

Content needs to be designed with responsiveness in mind to suit smaller screens
Interactive content needs to be scaled so it can be clicked by clumsy fingers

Accessibility testing

Visually there were already plenty of findings, but the key focus for a project like this had to be examining the flows - seeing how successful, or unsuccessful, I could be in completing desired actions.

I set out a few basic, common tasks which I could then test with each persona in mind. This allowed me to explore further tools such as mobile responsiveness, screen reader configuration and keyboard navigation.

Not only was this a fantastic way to uncover issues, but it really helped cement my accessibility knowledge through gaining some more lived experience using assistive tools and technology

Navigate the available topics
Complete an inquiry about nominating beneficiaries
Update my personal details

-->

Findings

How to present an accessibility audit?

In my week of exploration, I uncovered around 90 different issues with the portal.

The findings varied widely, from buttons with no visible focus state and page titles labelled simply as "container" to misleading language

This was far too much to take to the stakeholders in charge of this service. I also had to be mindful I was not dealing with technical stakeholders, but business leaders focused on return on investment into their propositions.

Because the personas had been so useful in uncovering issues and adding human context to the metrics, I chose to weave them throughout the presentation.

I was no longer telling them, for example, that an incorrect page title failed WCAG 2.4.2 at A level , but instead weaving a tale about Sam who opened a new tab to find their plan number and can no longer spot which of their 10 tabs open contains the form they were completing.

I got the biggest impact when presenting as I screen recording of the current experience, which included over 1 minute of the screen reader announcing the existing alternative text of an asterisk denoting a mandatory field.

Example audit findings

Post-audit activities

The slide deck containing my audit, while originally intended for a small group of immediate stakeholders, gained traction internally as an example of how we should be addressing accessibility concerns and why it matters. To date, I've received over 100 access requests from senior leaders throughout the business to help them understand our issues and empathise with them, including members of the C-suite.

I've also shared this presentation with other departments including technology and product management to help them better understand some of the accessibility concerns, and prevent them from being repeated in the future

Since presenting my audit, we've seen much earlier UX involvement in initiatives, as we've proven the value of our input early on for preventing rework like this.

Next steps

To keep momentum going, I took the personas, the most requested part of my audit, and turned them into easily shareable flashcards highlighting different users and their needs. I was able to collaborate with our vulnerable customers lead to understand some more niche vulnerability scenarios affecting our contact strategy, to build a more robust persona list.

The idea behind the cards was simple and functioned a bit like a Top Trumps, allowing anyone interested to pick a card at random and learn a bit more about a vulnerability they might not have thought about before.

The cards were designed to work both as a standalone learning activity, but also to be incorporated into some accessibility and inclusive design training planned.

Accessibility flashcards

Nyla

Illustrator, 32

Nyla is a freelance illustrator based in Leeds. She has Ehlers-Danlos syndrome, a connective tissue disorder which affects her joints, skin and energy levels.

Some days her condition is well managed, and can live her life to the full without thinking about it.

On other days she can manage fairly independently with the help of pain medication and mobility aids, like splints for dislocating joints or a cane for walking.

Sometimes the brain fog and pain can be too much and she has no choice but to rest. She has no control or influence over what level her illness will be any given day.

Chronic illness

Chronic illnesses come in all shapes and sizes, and no two days can look the same. It’s important users have the flexibility to be able to access a service when they need it, not when their condition allows.

Marcia

Teacher, 54

Marcia is a teacher in Greater Manchester, where she lives with her husband and teenage sons. She fell victim to an online scam last year, which saw her lose over two thousand pounds.

She has struggled with a great deal of shame after the scam, and feels very foolish.

She particularly feels that due to her work as a teacher, where she teaches her children not only English and maths, but life skills like critical thinking, she should have seen through the scam.

She has a lot of anxiety now from unexpected phone calls, and finds herself triple-checking any forms or agreements before sending them. She's also quick to abandon a task if she can't guarantee the security of it.

Trauma informed

Service users can need reassurance they can trust you, especially if they've been stung before. This reassurance can be built through words, imagery or actions.

Pierre

Gardener, 39

Pierre moved to Edinburgh from Lyon, France with his wife and children three years ago when his wife received a promotion.

He speaks conversational English, but struggles with the written language. He particularly struggles with formal language on official documents, and gets easily frustrated trying to use websites with too many words.

His daughter, Michelle, 12, often helps as Pierres unofficial translator, helping with forms or complicated processes over the phone.

Sometimes he gets even more frustrated as he knows the right words, but his accent gets in the way of people understanding him.

Language barriers

There are a lot of reasons a user could struggle to understand written or spoken language. Simplify where you can, or add imagery and alternative media to aid their understanding.

Inclusive design workshop

At our most recent team day, featuring 30 participants across design, research and management, I took the opportunity to run an inclusive design training workshop inspired by my findings.

I designed a hands-on accessibility training workshop to help teams experience the barriers different users face, building skills from empathy rather than from textbooks.

This workshop involved splitting into teams and receiving two persona cards, detailing realistic and relatable barriers like language, chronic health or money worries, and a common situation they had to design for.

Figma screenshot showing a component example

Insights

90+ accessibility and usability issues found in production legacy code
100 access requests from across the organisation for my audit findings

Learnings transformed into a workshop for 30 UX researchers, designers, managers and senior leadership

What I learned

Although this began as a side-of-desk task, it became a valuable learning and development opportunity. It proved that there is always more to learn about accessibility and inclusive technology. It also helped me understand some organisational resistance to accessibility enhancements; it's less about not seeing value and more about not fully understanding the scope, impact and benefits of it.