Lessons in accessibility: A day at the DfE Accessibility Lab and conversations with the experts
- Dr Sreemoyee Roy Chowdhury and Claire McShane
- May 1
- 6 min read
At the DfE Accessibility Lab, our colleagues Sree (User Researcher) and Claire (UX Designer) explored how assistive technologies are used—and where they can fall short when services aren’t designed with everyone in mind.
One crisp spring morning, as the sun finally pushed through the grey weight of winter, a user researcher, Sree, travelled from Newcastle and an interaction designer, Claire, journeyed from London, converging in Sheffield.
Their destination: the Department for Education’s (DfE) Accessibility Lab.
Their goal: to understand how digital services function for those who navigate the world differently.
Inside the Accessibility Lab: Where digital barriers become visible
We expected a technical demonstration—a run-through of tools and accessibility best practices. What we got was something much more human: a window into the lived experience of those who rely on assistive technologies daily.
Guided by Jane Dickinson, an accessibility specialist at DfE, we explored tools like Dragon, JAWS, ZoomText, and Fusion. Jane not only explained how they work but showed us how easily they can fail when services aren't built with accessibility in mind.
Insights from testing with assistive tools
Dragon: Voice recognition for hands-free navigation
Dragon voice control lets users navigate computers hands-free. But if clickable elements aren’t properly coded as buttons, Dragon can’t find them.
Jane demonstrated how Dragon struggled with buttons on a DfE service and the BBC homepage as they weren’t coded as such. Dragon couldn’t recognise the “click button” command as the button was invisible to the tool - highlighting a major gap between design and code.
JAWS: Screen reader for non-visual navigation
JAWS relies on well-structured content: heading levels, labelled buttons, and descriptive links. Jane showed how generic links like “Read more” or “Download” confuse JAWS users due to a lack of individual distinction or missing ARIA labels, making browsing chaotic and frustrating.
As Jane put it:
“If a page isn’t structured properly, it’s a nightmare to navigate.”
ZoomText: For low vision users
ZoomText is a magnification tool that helps users navigate visually. However, it requires users to hover or click on links to have them read aloud, unlike JAWS, which reads automatically. At higher magnification, text can become distorted where the page has not been coded to handle zoom, affecting readability.
Fusion: Combining JAWS and ZoomText
Fusion provides auditory feedback and high-level magnification for individuals with partial vision loss, offering magnification up to 20x with auditory feedback. But Jane showed us that even a 3x zoom can cause layout issues, like pixelation and clipped content, especially when sites don’t reflow content properly.
Keyboard-only navigation
Keyboard navigation is essential for users who can’t use a mouse, relying on shortcuts like the Alt key. But inconsistent implementation makes things harder. Jane pointed out unmarked buttons on the BBC homepage that would leave keyboard users guessing:
“If something isn’t labelled properly, it just gets skipped over.”
Captions for hearing impairments
Captions aren’t just for deaf users—they help everyone. But live captions often lag, making comprehension harder. Testing BBC video content, we saw captions fall out of sync with speech, making it difficult for a user to keep track.
Experiencing the world through the eyes of others
As part of our lab experience, we tested simulation glasses that aimed to alter vision, giving a general insight into conditions like:
Cataracts: everything looks blurred.
Tunnel vision: loss of peripheral vision, reducing situational awareness.
Left-sided hemianopia: half the visual field disappears, common after strokes or brain injuries.
It was very insightful to be reminded how much of the digital world can become difficult to use under these conditions, and how inclusive and thoughtful design can prevent the digital barriers that some users may face.
N.B. While simulation glasses offer a glimpse, they can’t replicate the full experience of visual impairment. They’re a starting point for empathy, not a substitute for listening to real users who experience visual impairments. To truly understand, we need to speak with and learn from real users.
In conversation with Accessibility Experts
To deepen our understanding of accessibility, we interviewed Jane Dickinson and Jake Lloyd, two key accessibility specialists at DfE, to hear their insights.
Jane’s biggest frustration? Accessibility being bolted on at the end.
“It’s not enough to test for accessibility. Real users need to shape the design from the beginning.”
She also highlighted how many users hesitate to disclose their accessibility needs for fear of being seen as difficult. Even when reports are written to improve accessibility, they often go ignored.
“I can spend a whole day writing a report, and sometimes nothing changes.”
Despite these challenges, Jane celebrated the wins—a blind user who was able to access their payslip independently for the first time:
“One of our blind users told me, ‘For the first time, I didn’t have to ask someone to read my payslip. I could do it myself.’ That made all the work worth it.”
Even small changes like properly marking up pdfs or labelling buttons has a huge impact and can make a service more accessible.
Jake emphasised the importance of building for keyboard navigation and screen readers from the very start.
“There are so many accessibility issues that come from not thinking about keyboard accessibility… It affects focus, visibility, and how well voice and assistive tech tools work.”
He highlighted issues like repetitive, unclear links in patterns such as “Check your answers”:
“Something like the ‘Check your answers’ pattern has links that just say ‘Change’… If you're just using a screen reader and you're navigating through a bunch of links… you're only going to hear “change”. So providing some hidden screen reader text, giving more context to that link can be really helpful.”
This was another thoughtful reminder that different users read pages differently, and not everyone will be able to view the visual context to written content.
A holistic approach to accessibility
The accessibility specialists broke down their layered approach to testing the accessibility of services:
Automated testing to catch common issues early.
Manual testing using only a keyboard or different zoom levels.
Assistive tech checks like screen readers and voice controls.
Code reviews to ensure correct HTML and component use.
As Jake put it, accessibility goes beyond the Web Content Accessibility Guidelines (WCAG) standards:
“I’ll also record issues that don’t fail WCAG but still create barriers—like having to tab 30 times to reach an ‘apply filter’ button.”
Jake warned against treating accessibility as an afterthought:
“Where teams haven't thought about accessibility and inclusive design up front and early on, complex issues tend to come out of that.”
Not boring. Not optional.
A myth Jake wants to debunk is that accessible design equals boring design.
“You can still be innovative. Your website can look good and be accessible if you plan it that way from the start,” he said. “Unfortunately, some organisations continue to treat accessibility as an afterthought, which remains a cultural issue”.
Our specialists pointed out that advocacy and awareness are key to changing this mindset:
“Having people with actual lived experience that can demonstrate the way that they interact with digital content, can be really powerful… Here's someone who is blind. They use a screen reader to navigate your service, and they can't do it.”
They stressed how one in four people have a disability—can you afford to turn them away with inaccessible services?
Why accessibility matters for everyone
Jane and Jake made it clear: accessibility isn’t just for disabled users. It benefits all of us. Captions help on a noisy train. Good contrast helps in bright light. And if zooming to 400% breaks your layout—it’s not just low vision users who suffer.
“If it’s not thought about up front, then it affects a lot of people.”
Accessibility isn’t a task—it’s a mindset
As user researchers and designers, we focus on how people interact with digital services. But in Sheffield, we were not the experts—we were the students.
This wasn’t about checking off accessibility guidelines. It was about understanding what happens when those guidelines aren’t met. A missing label, a broken heading structure, or an unlabelled button—these aren’t small issues. Each one determines who gets to participate and who doesn’t. Accessibility is also never ‘done’, it is an ongoing activity that requires the whole team's input to maintain.
As we left Sheffield, catching our trains to opposite ends of the country, we carried more than just knowledge. We carried a quiet but certain resolve to champion accessibility.
The best accessibility work doesn’t “help” people. It supports their independence and ensures they don’t have to ask for help in the first place.
Useful resources
About the authors
Sree is a Lead User Researcher specialising in uncovering user needs and delivering data-driven insights. A CDDO-DfE trained Service Assessor, she champions user-centricity and accessibility in government services. When she’s not diving into research, Sree can be found roaming the countryside with her husky, cooking up a storm, or curling up with a good book.
Claire is a Senior User Experience Designer, specialising in interaction design. She advocates for accessibility and strives to bridge the gap between usability and inclusion. Outside of work, Claire enjoys exploring new places and experimenting with new recipes.
Contact information
If you have any questions about our research and design services or you want to find out more about other services we provide at Solirius, please get in touch (opens in a new tab).
Comments