Accessibility isn’t an audit. It’s organisational change.

When I joined TUI, accessibility wasn’t something nobody cared about. Quite the opposite. There were people across the organisation who cared deeply about it. Some teams had started making changes, designers had received some initial training, and there were individuals with accessibility knowledge from previous roles, self-learning or simply because it was something they were passionate about.

But the effort was fragmented. Some people were trying to push accessibility forward within their own teams, but in an organisation the size of TUI, one person doing the right thing in one part of a customer journey can only get you so far.

You can design one accessible component, but if someone cannot get through the previous step of the journey, they will never reach it. You can train your designers, but if accessibility stops at design and never reaches development, content, testing or product decisions, the customer experience still will not be accessible. And you can fix everything identified in an audit, but if the organisation continues working in exactly the same way afterwards, accessibility issues will start appearing again.

That was the real challenge. It wasn’t simply about fixing accessibility issues on a website. We needed to change how we worked.

We started with one component

I didn’t arrive at TUI with a finished accessibility transformation framework in my pocket. The first thing we did was much smaller.

We chose one complex component and tried to make it accessible properly, from beginning to end. It was a calendar used as part of the holiday booking journey, so not exactly the easiest place to start. There were lots of interactions and states to think about, and getting it right required input from more than one discipline.

We brought together people from design, development, testing and product who already had some accessibility knowledge and worked through the whole development lifecycle together.

That first project was incredibly useful. Obviously, one accessible component was never going to transform the whole website, but it allowed us to test how accessibility could actually work inside our organisation. We could see where we were already strong, where the gaps were, and importantly, what happened when designers, developers, testers and product people were given the opportunity to solve the problem together rather than accessibility being handed from one discipline to another.

The component was successfully released, and we saw improvements that went beyond accessibility. The overall performance of the component improved too, including conversion.

That became an important part of the story. Accessibility was not simply something we needed to do for compliance. We had a real example showing that making something easier and more inclusive to use could make the experience better more broadly.

Around the same time, TUI was also audited externally by the Civil Aviation Authority. The audit added external pressure and further evidence that accessibility needed attention. But an external audit on its own would never have been enough.

We could have fixed the problems identified in the audit, passed another review and moved on. And then built more inaccessible things.

We wanted something more sustainable than that.

From understanding the problem to setting the vision

Once we had completed that first component, we knew much more about our starting point. We knew what was already working, where we lacked skills, where collaboration was breaking down and why making a few quick fixes would never create an accessible digital experience across a complex set of products and customer journeys.

But understanding the problem was only one half of it.

We also needed to agree where we wanted to go.

The vision we set was simple but ambitious: every customer should be able to find, book and manage their travel online, regardless of their abilities.

That gave us something much bigger to work towards than fixing individual accessibility issues. It meant thinking across complete journeys, across teams, across disciplines and across different parts of the business.

The question became:

How do we get from where we are now to that vision, and how do we do it at scale?

At this stage, leadership support became incredibly important.

There is a lot of discussion in accessibility about whether change should be top-down or bottom-up. I think the reality is that you need both, but you do not always get both at the beginning. Sometimes building leadership support is part of the transformation itself.

We already had passionate people pushing accessibility forward from inside teams. What we now needed was enough organisational backing to give that work momentum.

I started running sessions explaining why accessibility mattered and introducing product teams to the subject. At this stage, the conversation was less about exactly how to do everything and more about why this needed to become part of the way we built digital products.

And inevitably, the questions started coming. How are we going to do this? Do we have the skills? How much extra time will it take? Can we realistically make everything accessible?

Those were completely reasonable questions.

Toward the end of that first phase, I presented what we had learned to the wider department. I showed the work we had done on the first component and the success we had seen. I talked about the gaps we had identified, included the findings from the external audit, set out the vision for where we wanted to go and proposed how we could move from improving isolated components to improving accessibility at scale.

I still remember our director responding to the presentation by telling the room to listen to me because I knew what I was doing.

It was a small moment in the bigger transformation, but an important one for me. It didn’t suddenly mean every product owner was deeply invested in accessibility, and it didn’t magically remove all the competing priorities. But the conversation shifted. There was less resistance to having the conversation in the first place. More ears opened.

And that gave us space to build.

By then, we understood where we were and we had agreed where we wanted to go.

That was where our accessibility framework was born.

The four pillars that emerged

Four areas became fundamental to the way we approached accessibility. They weren’t independent activities. They worked because they supported each other.

1. Awareness and skills

One of the clearest things we discovered early was the scale of the skills gap. There was accessibility knowledge inside the organisation, but it wasn’t distributed evenly. Some people knew a lot, some knew the basics, and others had barely encountered accessibility in their work.

One of the first things I created was a central Accessibility Hub.

This became the trusted place people could go to find the accessibility information they needed: our standards, guidance, frameworks, templates, training, useful tools, processes and practical resources. Instead of people searching independently, finding conflicting information online or wondering which guidance they were expected to follow, we wanted to give everyone one place where they could find information they knew was relevant to the way we worked at TUI.

Initially, it was very much an MVP. We brought together the guidance we already had, useful resources, existing frameworks, templates and practical information about what teams could start doing immediately.

We found free accessibility training that people could access while we built the case for greater investment. Later, we secured budget for more specialised training from an external consultancy, tailored to different disciplines.

That distinction mattered. A developer does not need exactly the same accessibility training as a content designer. A designer needs different practical knowledge from a tester. Product people need to understand how accessibility affects prioritisation, planning and delivery.

We also created practical tools to help people apply what they were learning. For example, I created an audit template and trained teams in how to use it.

I started the Accessibility is not rocket science webinar series, short sessions designed to make accessibility feel approachable rather than overwhelming. They were deliberately short, around half an hour, so people could realistically fit them into their working day. Other members of our accessibility community ran sessions too, sharing expertise within their own disciplines.

Over time, those sessions reached a large group of people across the organisation.

But formal training was only part of it. We also created accessibility clinics where people could bring a question, a design, a technical challenge or something they simply wanted reassurance about.

There was no judgement. Some questions were incredibly simple. Others were complicated enough that we could not answer them immediately and needed to take them back to the wider working group. Both were equally welcome.

And something interesting happened. We started noticing the same questions appearing again and again.

That told us something.

Instead of repeatedly answering the same questions one person at a time, we could turn those patterns into shared guidance and resources and add them back into the Accessibility Hub. The clinics therefore became more than a support mechanism. They became another way of learning what the organisation needed from us and continuously improving the support we provided.

2. Collaboration

Accessibility cannot belong to one discipline, yet that is often exactly how organisations try to deal with it.

Developers might expect designers to specify everything. Designers might assume developers will know how to make the implementation accessible. Everyone might assume testers will catch the problems at the end. Content teams can find themselves blamed when content creates an accessibility problem, while content people might reasonably point out that they are working inside an experience that was not designed or built accessibly in the first place.

The problem is not that any of those people do not care. The problem is that accessibility falls into the gaps between disciplines.

Our first component had already shown us what could happen when those disciplines worked together. The original group evolved into an Accessibility Working Group, bringing together people from design, development, testing, product, content and eventually different products and markets.

That group became a place where we could share knowledge, solve problems together and support each other.

But we knew a small central group could not make every product accessible, so we expanded the model through accessibility champions. Instead of a few accessibility people trying to do everything, knowledge and advocacy could live inside individual teams.

That was important for scale, but it also changed relationships between disciplines. Designers had better access to developers with accessibility expertise. Developers could influence decisions earlier, rather than receiving designs at the end and being expected to make them work. Testers helped teams understand how things needed to be validated. Product people were part of the prioritisation conversations. Content was involved in creating experiences that worked as a whole.

Accessibility stopped being something that moved mechanically through a delivery pipeline. It became something people discussed and solved together.

3. Consistent standards, processes and ways of working

Training people is not enough. You can give ten teams the same training and still end up with ten completely different ways of implementing it.

We saw that very quickly.

Different teams were using different accessibility tools. That made it harder to share knowledge, but it also created another problem: the tools did not necessarily produce comparable results. One team could assess something one way and another team could arrive at a completely different picture.

So we started standardising. We agreed tools, created templates, developed shared approaches for audits and created ways of annotating designs for accessibility. We looked at handovers, talked about accessibility within definitions of ready and definitions of done, and clarified responsibilities across disciplines.

This was not about creating bureaucracy for the sake of it. It was about removing the need for every team to reinvent the process.

Once we had worked out a good way of doing something, another team could use it rather than spending weeks working out their own approach. It also meant people could move between teams and encounter familiar expectations, standards, processes and ways of working.

One small example was accessibility annotations in design.

It would have been easy to decide that designers should document absolutely everything for developers. But when we discussed the process together, we realised that was not necessarily the best solution.

Developers already understood many standard accessibility requirements. Sometimes there were existing components they could use. Sometimes they knew a better technical solution than the one a designer might prescribe.

So we agreed that designers would annotate the things that were important or unusual rather than documenting every default behaviour. That saved design time, avoided unnecessary prescription and gave developers space to use their own expertise.

That is why I think good accessibility governance should enable people rather than police them.

Eventually, these standards, responsibilities, processes and ways of working became part of the digital accessibility policy I created for our e-commerce organisation.

By that stage, we were no longer relying on individual people remembering what good accessibility looked like. We were starting to build it into the system.

4. Improving the actual customer experience

Of course, none of this matters if the website itself does not become more accessible.

So the fourth pillar was about translating all of that capability into improvements customers could actually experience.

I mapped our key user journeys across the digital estate. That included the journey from search and browse through booking and post-booking, but also different products such as holidays, flights, accommodation and cruises.

Then we needed to understand where we stood.

Using the shared audit approach we had developed, teams assessed the key pages, components and journeys within their areas. At that point, our testing teams did not have the capacity to perform all of that work themselves, so design stepped in.

That was important to me.

As designers, we are responsible for the quality of the experience. If we know something needs to be understood and there is a gap in capability somewhere else, we do not have to sit and wait for another discipline to tell us what is wrong.

We can take ownership.

Teams learned how to carry out accessibility audits and created a much clearer picture of the experience. That gave us a benchmark, but it also gave us a very long list of things that could be improved.

And this is where accessibility transformation meets the reality of product development.

You cannot always say, “Everything must be fixed immediately.”

There are deadlines, technical constraints, legacy systems, competing customer and business priorities and teams with different levels of capability. There were many conversations and negotiations about what needed to happen now, what could happen later and what needed to go onto a longer-term roadmap.

We prioritised. We looked for quick improvements where they made sense. We pushed for new experiences to be accessible when they were being created. And we looked across complete journeys because making one isolated step accessible is not enough.

If one team creates a beautifully accessible third step of a journey but a customer cannot get through step one, the overall journey is still inaccessible.

That created a shared dependency. Our teams needed each other.

And slowly, something changed.

The real transformation

Over time, I started seeing teams sharing what they had improved.

“We’ve made this accessible.”

“We’ve fixed that.”

“We’ve changed this journey.”

It almost became a friendly competition, although nobody formally made it one. People were proud of what they were improving.

That was very different from the conversations at the beginning.

The questions had changed.

Instead of:

Why do we need to do this?

we increasingly heard:

How do we do this?

For me, that is one of the clearest signs of accessibility maturity.

It is not simply the number of accessibility issues you have fixed. It is whether people across the organisation understand why accessibility matters, have the capability to do something about it and see it as part of their own work.

And we could see that cultural transformation reflected in the results too.

Within roughly 18 months, our internal accessibility maturity measure had increased by 325%. We went from having only a handful of user features that had been reviewed and approved as accessible to more than 100.

Those numbers mattered because they showed progress, but they were not the transformation itself.

The transformation was that accessibility was becoming embedded into how people thought, collaborated, designed, developed, wrote content, tested, prioritised and delivered digital products.

An external agency can audit your website. You can fix everything they find. They can come back and verify that it has been fixed. But if nothing changes in the organisation behind that website, the next release can introduce accessibility problems all over again.

That is why I no longer think of accessibility transformation primarily as an accessibility problem.

It is an organisational change problem.

You need awareness and skills. You need collaboration. You need clear standards, processes and ways of working. You need leadership support. You need people who are willing to take ownership. And you need to give teams the tools, knowledge and confidence to apply all of that to real products, within the very real constraints of running a business.

Accessibility maturity does not come from one audit, one training course or one passionate accessibility specialist.

It comes when accessibility becomes part of how an organisation thinks, works and builds.

The real transformation happens when people stop asking why accessibility is their responsibility and start asking how they can make it happen.