A simple example of how accessibility helps everyone

Posted: Thursday, 28 August 2025

When accessibility is your day job, you all too often see accessibility issues on the web that make you wince. Today was one of those days.

I was cooking tea (or dinner if you're not from Yorkshire). The kids were telling me about their days while I was cooking up their favourite spaghetti bolognese. I'd had my car serviced earlier in the day. I got a text message from the dealer that linked to a "vehicle health check" video - where they walk you around the car and talk you through any potential issues. As the kids dashed off to play outside, I grabbed my phone with one hand, while trying not to burn the mince I was frying.

I hit the link expecting to see the video...

The problem

Instead, I was taken to a form where I needed to enter my car registration number, postcode and, mobile number.

A mobile web browser showing an authentication page. The page has 3 text inputs - registration number, email address and mobile number. The screen is laid out in a way that suggests it was not built responsively and only for larger screens with the input labels positioned to the left of the inputs.

The first red flag: the page wasn't responsive. Nothing stacked neatly into a single column - the usual mobile-first/responsive pattern.

Ignoring this, I tapped on the registration number input, which is when things got frustrating.

The same authentication page, with the first input focused. The screen has shifted to the right with the input labels no longer visible.

The screen shifted and zoomed slightly so that labels disappeared off the left side. This happened for every field: car reg, email and mobile number.

Trying to type one-handed while cooking and keeping an eye on the kids, I had to constantly scroll left and right just to remind myself which field I was in. Frustrating, especially when you know how easily this could have been avoided. Not to mention this is also a failure of WCAG 1.4.10 Reflow (AA).

The same authentication page, with the first input focused after scrolling back to the left to see which label matched up with which input

For me, it was just an annoyance. But for someone with motor control challenges or cognitive impairments, this would have been a much bigger barrier.

Digging deeper

Later in the day, I decided to take a deeper look at the page to see what other issues lurked. After inspecting the page in Chrome DevTools, more issues were found.

Page basics

No language set on the <html> tag, failing WCAG 3.1.1 Language of Page (A)
No page landmarks at all, potentially making navigation harder for screen reader users
No initial zoom level set due to missing initial-scale=1.0 on the viewport meta tag's, which can cause zooming and layout problems

Forms and labels

Labels weren't programatically associated with inputs (missmatched for and id values), failing WCAG 1.3.1 Info and Relationships (A) and 4.1.2 Name, Role, Value (A)
No autocomplete values on email or mobile inputs, failing WCAG 1.3.5 Identify Input Purpose
Form errors were communicated by text but were not programmatically associated with inputs, arguably failing WCAG 1.3.1 Info and Relationships (A)

Content and layout

Header links and images visible at wider screen widths were hidden on mobile, failing WCAG 1.4.10 Reflow (AA)
Empty headings were present, failing WCAG 2.4.6 Headings and Labels (AA)
Linked images had no accessible names (no alt text, ARIA or visually hidden text), failing WCAG 4.1.2 Name, Role, Value (A)
Text was small and the default iOS focus outline was low contrast, making everything harder to see and use.
Percentage-based widths on labels and inputs with no media queries for smaller screen sizes / higher zoom levels (lack of responsive design)

What should have been done

This is a classic case where accessibility, usability, and good design overlap. These "vehicle health checks" are sent out by SMS, so almost everyone opening them will be on a phone. At the very least, the team should have tested the user journey on mobile, with and without a screen reader. Had this been done, almost all of the issues mentioned would have been caught.

None of of the issues are hard to fix, it's standard responsive, accessible design.

Here's a simple CodePen showing how the page could look, had it been built with accessibility in mind.

See the Pen Example responsive dealer sign in by James Jacobs (@jamesjacobs) on CodePen.

Conclusion

When you're designing, building, or testing something, don't just check it on your desktop. Try the full user journey on different devices and screen sizes, and against the baseline WCAG provides, using tools like screen readers, speech recognition, and built-in features found in almost all browsers and operating systems, such as zoom or magnification.

Doing this doesn't just help people with permanent disabilities - it makes life easier for anyone juggling everyday chaos: cooking dinner, sorting the kids, or trying to type one-handed. That's situational impairment in action, and this story is a perfect example.

Accessibility isn't just about compliance. It's about making things work for real people, in real life. And real life is messy: kids, cooking, one hand free. When you design, develop and test with that in mind, everyone wins.

Oh, and you'll be happy to know, I didn't burn the tea and the kids enjoyed spaghetti bolognese for the millionth time!