Michael Kennedy

Posted on Jun 9

UX Starts with Accessibility

#webdev #design #ux #a11y

Accessibility is often treated as a compliance exercise, but it shapes the quality of every user experience and the success of a product itself. It influences how people interact with software in ways that go beyond assistive tech. When accessibility is ignored, small usability issues impact engagement, retention, and commercial outcomes. In practice, accessibility isn't a technical or ethical consideration, but a driver of quality and ultimately financial success.

Accessibility is a legal requirement in the UK under the Equality Act of 2010, but digital products fall into the category of "reasonable adjustments". It's only under legislation for public sector bodies that WCAG guidelines come into play; for everyone else it's more a case of "just do the best you can".

As software developers, designers, testers and project managers we all play a part in the success of our projects, but all too often product accessibility and usability are forgotten about or left until the last minute in favour of big sexy features that rightly appeal to marketing teams and financial benefactors.

Accessibility isn't glamorous, but it also isn't difficult when considered from the start. Forget about it at your peril, a dozen small usability frustrations can damage a product just as effectively as a major technical failure. More often than not, there won't be a big error message giving users something to point at, accessibility issues have more nuance, are more likely to be seen as annoyances by non-technical users, things that they can't quite put their finger on because it makes the product feel more complicated than it should. Users won't commonly complain about these things, they'll just find a different product.

Accessibility for Everyone

From a technical perspective, accessibility makes us think of disabled users requiring screen readers, of people who need assistance using mouse and keyboard. There is of course, an element of this, but accessibility considerations are significantly more involved and impact all users.

Thinking outside of software for a moment, what accessibility improvements do we use every day without giving it a second thought?

Dropped kerbs and tactile paving.
Step-free building access and automatic doors.
Click‑and‑collect services.
Larger accessible station turnstiles.
Television subtitles.
Ergonomic mice, keyboards and tools.

All these and more were originally designed to close the disability gap and ensure that everyone has the same level of access regardless of their physical needs. Yet we see something interesting in how these things have become commonplace, used not just by people with physical disabilities, but by everyone.

The further we delve into this, the clearer it is that everyone is different and that we can all benefit from accessibility improvements.

In the UK:

3 in 5 people wear glasses ¹
3 million people have a colour vision deficiency ²
10% of the population has dyslexia ³

Even with just these simple statistics, there's a strong likelihood that a user working with a product we've written will have some sort of accessibility requirement. Do we cater to this; or pretend it doesn't exist, what we choose here says more about us as people than it does about the user needs.

When we pick a product, we'll compare different options; commonly we'll pick the prettier option, the option with the best features and most importantly - the product that's easiest to use, because happy users are users who will keep coming back. This is the crux of software accessibility, because the improvements we implement improve the lives of all our users, not just a small subset.

WCAG Guidelines

UK public sector bodies need to comply with the WCAG 2.2 AA standard. These extensive requirements are grouped into categories describing what it means for an interface to be usable by real people in real situations.

Perceivable
Users must be able to perceive the content, not necessarily just visually.

Content must have text alternatives where needed (e.g. images, media).
Video and audio must include captions or transcripts.
Information must not be conveyed by colour alone.
Content must remain readable and distinguishable.

In practice, this ensures users aren't forced to guess meaning from appearance alone.

Operable
Users must be able to interact with the interface in a reliable way.

The interface must be fully usable via keyboard.
Users must have enough time to read and interact with content.
Heavy motion and animation should be disabled or reduced.
Navigation and interactions should be consistent and predictable.

This is what prevents users from being blocked by interaction patterns they can't access.

Understandable
Users must be able to understand what the system is doing.

Language should be clear and defined.
Behaviour should be consistent and predictable across the application.
Assistance must be provided to help users avoid and correct mistakes.

This is the difference between a user making progress and a user guessing what went wrong.

Robust
Content must be able to be interpreted by a wide variety of assistive technologies.

Interface elements must be correctly identified by assistive technology.
Status changes should be announced without disrupting user focus.

This ensures the interface doesn't break when used outside of a "perfect" setup.

Outside of public sector bodies, these are of course, just guidelines, but that doesn't make them any less important; they provide a point of focus for designers and developers and we already know that changes for accessibility enhancements affect everyone positively.

Accessibility vs User Experience

When we think of the User Experience (UX), we tend to think about the way that a product fits together, how users will navigate around, how easy it is to find what we're looking for, colours, material design, glassmorphism and so on (that same stuff that the marketing team finds irresistible).

Accessibility isn't something that should sit separately from UX. Instead it informs design decisions, making sure we don't get too carried away with the latest trends, it grounds our designs in the real world in much the same way that a trusted colleague can spot when enthusiasm is starting to outrun practicality.

The two concepts sit side-by-side, it should never be a choice between accessibility or design, but both working together because a good user experience can only be built on a foundation of good accessibility.

Take the below real-world software issues, these are the sort of things that will annoy users in spite of any accessibility needs:

The Modal Pop-up

The user clicks a button that opens a modal window within the current page.

The button that opens the modal window retains focus. The user can tab into the modal, but it takes 50 presses of the tab key to do so.

The user can't close the modal by pressing the escape button or clicking the greyed out area around the modal. They look for the close button but the OK and Cancel buttons are positioned around the opposite way to a previous screen and it takes a moment to register the difference in behaviour.

Finally once the modal has closed, the focus remains on last control clicked and it takes another 50 tabs to return to the original position.

These examples cover some common issues under the Operable and Understandable categories. Components must be accessible by keyboard and their behaviour should be predictable. Users shouldn't have to learn a different set of interactions for each screen, whether that's the position of OK and Cancel buttons, the ability to dismiss a modal with the Escape key, or where they are returned to once a task is complete.

These are basic consistencies, things that should always happen, much like the expectation that hitting enter after entering search criteria will initiate a search without additional clicks.

Error Messages and Toasts

An error message appears on-screen when a user submits a form. The user has missed one of the required fields, there's no required identifier in the field label, there's no error message displayed adjacent to the missing field.

A toast message appears at the top of the screen advising the user that the form is incomplete, but doesn't provide details.

The toast is positioned in the top corner of the screen, but it overlaps and hides the menu items beneath it. Furthermore, the user needs to click an "X" button to hide the toast. Worse yet, the background colour of the toast is the same colour as the main menu and as a result the user doesn't see it immediately.

Finally, this is a modern SPA, when the user continues their journey, the toast message is left on-screen.

Here we see some common issues under the Perceivable and Understandable categories. If a user makes a mistake, the application should make it clear what the problem is and how to fix it.

By not making it clear which fields are required and showing generic warning messages user frustration is increased and task completion becomes slower.

Furthermore, error messages should be easy to see without getting in the way of other content or requiring the user to take actions to dismiss them. Finally, feedback should always be relevant to the users current task, persisting messages after the user has moved on can create additional uncertainty and confusion.

Screen Size and Zoom

A user has zoomed the content of their browser by 25% to make it easier to read smaller text without glasses.

When they zoom in, the layout of the page doesn't automatically adapt, a horizontal scrollbar appears at the bottom of the page. The user dismisses its appearance as an annoyance and continues.

They click a button which opens a drawer component, sliding in from the left. There's sufficient content at this zoom level for a vertical scrollbar to appear in the component.

There's an "X" at the top of the component which is hidden when the user scrolls. There are "OK" and "Cancel" buttons at the bottom of the drawer. When the user has scrolled half way down, all navigation buttons are hidden. The user needs to scroll to the top or the bottom of the component before they can close it and move on.

Here we see issues under the Perceivable, Operable and Robust categories. It's a typical example of developing a product to a specific screen size and not considering how it behaves across other display sizes. This is easy to fall foul of when developing on smaller laptop screens but can have unexpected knock-on effects.

By not considering scenarios such as screen size or the amount of content shown in a generic component we risk key information and controls becoming inaccessible. Instead of the interface adapting to the user, the user is forced to adapt to the interface.

These guidelines are often treated as compliance requirements, but in practice they describe the conditions for good user experience.

Accessibility Isn't a Checkbox

Modern libraries like Syncfusion, Telerik and Material UI work to ensure accessibility is provided at the component level. They can handle things like keyboard navigation and focus management straight out of the box.

There's no doubt that this provides a huge advantage, but accessibility can't be handled completely from a component library because individual components can't see the big picture, they can't adjust based on the application flow.

We can put inaccessible content within an accessible component; break accessibility with a misconfiguration, write error messages that only make sense to developers. Ultimately, we can't just set input.accessibility = true; and be done with it.

We can mitigate these issues with the usage of tools such as Lighthouse and WAVE; tools like this can identify contrast problems, missing alt-text properties and a plethora of other problems, but they can't tell you if a user is successfully able to complete a task.

There are things that just can't be achieved without careful consideration at all levels, but while there's a lot to consider, many accessibility improvements are small. A skip-to-content link can save keyboard users dozens of key presses. Reduced-motion settings can reduce discomfort for users with sensory sensitivities. Larger click targets benefit everyone using touchscreens. High contrast text helps users working outdoors, on poor displays or just at the end of a tiring day.

Small Frustrations, Big Consequences

Have you ever broken or fractured a bone and had trouble using the mouse or keyboard (it's not fun), strained to see small text on a screen, zoomed in on a website because the text is too small or struggled to click a tiny close button?

These are all common accessibility considerations, but they irritate all users. By tackling things of this nature from day one we're improving every user experience, not just those who use assistive technology.

A good real-world example of this would be autoplaying video previews on streaming platforms (I'm looking at you, Netflix, and your web-only options screen). Intended to help users discover content, but constant movement and unexpected audio can be distracting, particularly for users with sensory sensitivities, while also frustrating users who are simply trying to browse.

If you're reading this then you're likely a technical expert for your own applications, you instinctively know the oddities of its design and adjust to it because you live in it 24/7 (or at least 7½ hours a day), but most users don't have that level of technical knowledge of a single product.

Every time a user comes across a minor inconvenience it damages their impression of your product. If a big architectural problem brings your product down for hours then yes, you have problems that need handling immediately, but you know where the issue is and can deal with it.

UX issues are different. It's death by a thousand cuts, repeatedly damaging the reputation of a product. Worse yet, this isn't something that can be tracked as easily as downtime. Users rarely report every frustration; they simply walk away.

This is the true business case for accessibility. It should be treated with as much reverence as any other part of the software development lifecycle, because accessibility is the foundation of a good user experience. Without considering it from day one, we're not designing for our users—we're designing for our assumptions about them. And if UX is built on assumptions, it means nothing.

DEV Community