Making Eurostar.com 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.

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.

Political

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 issued any directives on how people should code or design.

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 (to them), how we could find and fix accessibility 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 disabilities 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 PRs (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 mobile screen-readers worked and this enabled those devs to test better and meant the team could produce a greater volume of accessible components.

Documentation

Everything was written down and documented and stored in the corporate Wiki. Every process was documented too, so whenever a question arose a link could be sent in response that answered 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:

• a JAWS (screen-reader) user
• a ZoomText (screen-magnification) user (who also inverted the colours on their Windows laptop)
• a Dragon Naturally Speaking (voice activation sofware) user

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