Making accessible

Over the course of 12 months, starting in 2022, Eurostar redesigned and rebranded their main website. As part of this, they wanted to make the new website accessible.

Screenshot of homepage

Defining what is 'accessible'

The first task was to decide what level we would suggest that Eurostar went for. When work started WCAG 2.1 was live and WCAG 2.2 was still a draft. We suggested to design/code for WCAG 2.2 Level AA because it was set to launch mid-build.


Once we decided our success criteria, we set about a process of making it happen. The first step was to contact almost every developer directly via Slack in a DM (direct message) and explain who we were and what the goal was.

We firmly believe, accessibility is as much a political issue as it is a technical one and the idea was to get everybody onside before we issuing any orders.

Train, review, fix

We gave every team member a 1 hour training session were we explained why we were making the new site accessible, how people might use the site in 'unexpected' ways, how we could find and fix bugs.

In this training, we gave a demonstration of how screen-readers worked but this was always saved to the end - despite it being the most popular part. This allowed us time and space to educate people on other types of disability and try to get them out of the mindset of accessibility equals blind people.

Post training, the developers coded new components and we reviewed that code in Github pull requests. Designs were made in Figma and comments were added to designs informing Designers what they needed to change in order to be compliant.

Once code was published, we went in and fixed any bugs/errors that got past us and the other developers.

This project was at times very hands-on.

Extra training

More screen-reader (VoiceOver on MacOS) training was provided to developers who were interested in learning about how they worked and this enabled those devs to test better and meant the team could produce a greater volume of accessible components.


Every was written down and documented and stored in the Eurostar Wiki. Every process was documented so whenever a question arose a link could be sent in response that covered the answer to that person's question.

Third party testing

We lead the procurement process for a third party agency to audit the new site and to test it with disabled users. The decision was made to work with dac and we spent time reviewing videos of demos with the Eurostar team. The team were fascinated by the real life demonstrations of assistive tech that we saw which included:

These demos enabled the team to see problems that had been missed and we set about a plan to fix any issues found.

Want to work with us?

Let’s talk about your project