Accessibility is simply good user experience
Author: Dan Clark 7th Jul 2026 13 minutes read
Accessibility has become a much more familiar part of website projects over the past few years.
For many organisations, the first encounter with accessibility comes through legislation or procurement. A website brief references the Web Content Accessibility Guidelines (WCAG), an accessibility statement becomes a project requirement, or somebody asks whether the finished website will be compliant. Those are important questions to ask. For many public sector organisations and publicly funded bodies, accessibility is not simply good practice. It is a legal responsibility under UK accessibility legislation.
What has always interested us is how quickly those conversations evolve once a project begins.
Although accessibility may enter through compliance, it rarely stays there. The discussion soon moves away from standards and towards people. It becomes less about individual success criteria and more about the hundreds of decisions that influence whether someone can use a website confidently and independently. By the time a project reaches launch, accessibility has usually become woven into design, content, development, testing and governance in ways that weren’t immediately obvious at the outset.
Looking back across the projects we’ve delivered, that’s probably the biggest lesson we’ve taken from accessibility. Meeting recognised standards is part of the picture, but it isn’t where accessibility stops. Over time, it becomes another way of improving the quality of a website and the experience people have when they use it.
Compliance is an important benchmark, but not the destination
When organisations first discover they have accessibility responsibilities, the natural response is to ask what needs to be done. That’s entirely understandable. The Web Content Accessibility Guidelines provide an internationally recognised framework for making digital services more accessible, giving organisations a shared standard against which websites can be designed, developed and assessed.
Those standards matter.
Without them, accessibility would become subjective and inconsistent. WCAG provides clarity, raises expectations across the industry and helps organisations understand where barriers may exist. Every guideline exists because it addresses a genuine problem that prevents somebody from accessing information or completing a task successfully.
At the same time, we’ve found that the most valuable accessibility conversations rarely revolve around the wording of a particular success criterion.
Instead, they revolve around much simpler questions.
- Can somebody find what they’re looking for?
- Can they understand what they’re reading?
- Can they complete the task they came to do without unnecessary frustration?
The standards remain an important reference throughout the project, but they gradually become the framework supporting those conversations rather than replacing them. That’s an important distinction because organisations sometimes assume accessibility is primarily about satisfying a standard, when in reality the standard exists to support a better experience.
One practical lesson we’ve found is that accessibility is almost always easier to address when it’s considered early. Once visual designs have been approved, content written and functionality developed, accessibility improvements can sometimes feel like compromises. Earlier in the process, those same discussions simply become part of good design.
That doesn’t necessarily make accessibility cheaper, but it often makes it far less disruptive. Colours can be refined before they become embedded throughout an interface. Navigation can evolve while user journeys are still being mapped. Content structures can be improved before hundreds of pages have been created.
Perhaps the best advice we can offer organisations starting a new website project is not to ask when accessibility testing should begin, but when accessibility thinking should begin. In our experience, the answer is almost always the same: as early as possible.
Accessibility becomes part of everyday decision making
One reason accessibility can feel daunting is that people often imagine it as a specialist activity that happens separately from the rest of a website project. In practice, it rarely works like that.
Accessibility tends to appear wherever important decisions are made. It influences information architecture, branding, content design, interaction design, development, testing and editorial processes. Sometimes those conversations are significant, but more often they emerge through dozens of relatively small decisions that collectively shape the finished website.
A good example is something as simple as a button.
A client may naturally choose white text on a red button because it feels familiar and complements the brand. Depending on the colours involved, that combination may not provide sufficient contrast for many users. Black text may perform considerably better, even though it initially feels less intuitive visually.
It’s easy to see how conversations like this could create the impression that accessibility means changing an established brand. In reality, that is very rarely the discussion we’re having. Organisations may have years of brand recognition behind them, reflected across printed literature, signage, advertising and other materials that aren’t realistically going to change because of a website project.
In our experience, it’s rarely a question of changing the brand. More often, we introduce a complementary set of interface colours or avoid using particular colours where contrast is especially important, such as buttons, alerts or navigation. The organisation keeps its visual identity, but the website becomes easier for more people to use.
We’ve found accessibility often works best when it encourages better decisions rather than forcing unnecessary compromise. It rarely asks organisations to abandon what makes their brand recognisable. More often, it encourages teams to think differently about how that brand is applied within a digital interface.
That’s an important distinction because accessibility is sometimes perceived as the discipline that tells projects what they can’t do. Our experience has generally been the opposite. The conversation is usually about finding another way to achieve the same objective, one that preserves the organisation’s identity while making the website easier for more people to use.
Perhaps that’s one of the most valuable things accessibility brings to a project. Rather than acting as a barrier, it encourages teams to step back, understand the challenge and find a solution that supports both the organisation and the people who use the website. Those solutions are often more considered than the original approach, not because accessibility demanded compromise, but because it encouraged better design.
The same pattern repeats throughout a project. A bespoke navigation may look impressive until somebody tries to use it with a keyboard. Downloadable PDFs raise questions about how accessible they’ll remain once they’re opened outside the website. The discussion then moves to videos, captions, transcripts and other ways to make the same information available.
None of these decisions fundamentally changes what the website is trying to achieve.
If anything, they usually strengthen it by encouraging teams to think more carefully about how information is presented and how people interact with it. That’s one reason we’ve gradually stopped seeing accessibility as something that sits alongside user experience. It increasingly feels like a way to achieve good user experience.
Experience still matters
Accessibility is often associated with automated testing and rightly so. Modern accessibility tools have become an essential part of website development, identifying many technical issues quickly and consistently. Missing alternative text, heading hierarchy, HTML structure and numerous WCAG checks can all be identified far more efficiently than through manual review alone.
Those tools are incredibly valuable, but they are only part of the picture.
One of the more surprising things we’ve found over the years is that some of the most important accessibility conversations begin where automated testing ends.
Automated reports are excellent at finding technical issues, but they don’t give you the full picture. A page may support keyboard navigation while still feeling awkward to use. A heading structure may be technically correct even though the content is difficult to understand. That’s where judgement becomes just as important as the technical requirements.
That’s one reason independent accessibility audits can be so valuable.
Where budgets allow, a thorough audit, particularly one that includes people with lived experience of using assistive technologies, often identifies issues that development teams and automated tools alone would never discover. That additional perspective can be invaluable because accessibility is ultimately experienced by people rather than software.
At the same time, we also recognise that not every organisation can commission comprehensive external audits for every project. Accessibility shouldn’t be achievable only for organisations with the largest budgets. Professional judgement, regular review and a genuine commitment to continual improvement remain just as important, particularly where resources are more limited.
We’ve found that accessibility exists on a spectrum. Some organisations have the budget to commission comprehensive external audits, undertake user testing and revisit interfaces several times before launch. Others simply don’t have those resources, despite having the same desire to improve accessibility.
That doesn’t mean accessibility becomes less important. It means organisations need to make thoughtful decisions about where their efforts will have the greatest impact, combining automated testing, judgement and continual improvement in a way that is proportionate to their circumstances.
Accessibility doesn’t finish when the website launches
After launch, accessibility becomes less about development and more about day-to-day publishing. Developers and designers establish the technical foundations, but every new page, document and video can either strengthen or weaken the website’s accessibility. Editors still need to write alternative text, structure content carefully, prepare accessible documents and provide captions or transcripts where they’re needed.
Those responsibilities often surprise organisations because they’re not really website development tasks. They’re editorial and organisational responsibilities.
We’ve seen technically excellent websites gradually become less accessible over time, not because the platform was poorly built, but because accessibility hadn’t become part of the organisation’s day-to-day content processes. Equally, we’ve worked with organisations where accessibility became part of editorial culture, with content teams understanding their role and continually improving the website long after launch.
Accessibility follows much the same pattern as performance, security and content quality. Strong technical foundations matter, but maintaining standards depends on the decisions people continue making every day.
Good accessibility requires judgement
One aspect of accessibility that often receives less attention is informed judgement.
It would be easy to think that every accessibility decision has a simple right or wrong answer, but real projects are rarely that straightforward. Organisations have existing brands, complex systems, limited budgets and years of accumulated content. Improving accessibility often means understanding how to make meaningful progress within those realities rather than pretending they don’t exist.
The principle of disproportionate burden reflects that reality. It’s sometimes misunderstood as a way of avoiding accessibility responsibilities, but that’s not its purpose. Organisations may need to prioritise improvements where resources are limited, while still addressing barriers that prevent people from accessing information or completing essential tasks. The principle recognises that budgets, competing priorities and large amounts of legacy content all influence how quickly improvements can be made. What matters is continuing to make meaningful progress.
We’ve worked with organisations that have brought together multiple legacy websites into a single modern platform. Building the new website to current accessibility standards was only one part of the project. Hundreds of historic PDF documents also required attention, many of which had been created years before modern accessibility standards were widely understood. Updating every document before launch simply wasn’t realistic. Ignoring the issue wasn’t acceptable either.
Instead, the organisations acknowledged the work that remained, published clear accessibility statements, prioritised documents according to need and continued to improve the library over time as resources allowed.
That’s why we’ve never seen accessibility as something that’s finished on launch day or measured by a single pass or fail result. What matters is continuing to remove barriers, being honest about what still needs attention and improving the experience over time.
Accessibility is ultimately about people
Perhaps that’s why our own perspective on accessibility has changed over the years.
The more projects we’ve delivered, the less we’ve thought about accessibility as a separate technical discipline and the more we’ve seen it as another way of understanding people.
Better semantic HTML helps screen readers while creating a clearer structure for search engines and AI systems. Clear navigation makes websites easier to move around, whether someone is using a keyboard or a mouse. Logical heading structures help assistive technologies interpret a page, but they’re just as useful for someone quickly scanning the content before a meeting.
None of those improvements exists because of AI, search engines or compliance. They exist because they help people use websites more successfully. The wider technical benefits follow naturally from that.
Accessibility will quite rightly continue to be shaped by legislation, standards and compliance. Those things are important because they establish a common expectation and help organisations deliver more inclusive digital services. They should never be dismissed or treated as optional.
The projects that leave the strongest impression on us, however, are rarely the ones that simply achieve compliance. They’re the ones where accessibility quietly changes the way people think about the website they are building.
Perhaps that’s one of the less obvious benefits; that’s why we’ve gradually stopped thinking about accessibility as something separate from good user experience. It doesn’t ask organisations to stop being themselves or to compromise the purpose of their website. More often, it asks them to understand their users a little better and to make more thoughtful decisions about how the website supports them.
Compliance will always remain an important benchmark and for many organisations it is rightly a legal responsibility. The opportunity is not to stop seeing accessibility as an obligation, but to stop letting it remain only an obligation. When accessibility becomes part of how a website is planned, designed, developed, and managed, it usually leaves the website stronger than it would otherwise be.
In the end, the real value of accessibility isn’t found in compliance alone. It’s found in websites that are easier to understand, easier to navigate and easier for more people to use.
Explore this further
User experience and accessibility: a complete guide
Understand how user research, journeys, information architecture, accessible design and usability testing work together to…
What is user experience (UX)?
Learn what user experience means, how UX research and testing work, and why reducing unnecessary…
Website accessibility explained
Learn what website accessibility means, how WCAG 2.2 applies, how accessibility is tested and how…
User journeys explained
A great user journey makes every interaction feel effortless. Learn what user journeys are, why…