How we began building accessibility into Premier Inn
There are many benefits to creating your site in an accessible way — the chance to sell to more customers, having a positive brand impact, and not getting sued. One of the more eye opening experiences I’ve had in thinking of ways this helps others is reading this article: An Alphabet of Accessibility Issues. It shows the range of disadvantages people can have at any time in their life where accessible features can help and that it’s not just for the severely disabled. Yes we should be building for the deaf but those video captions will also help the commuter who forgot their headphones.
How we started
So, we wanted to bring this thinking into Premier Inn and the first thing we did was create a working group. It included people from design, data, development, and QA. Starting off, we wanted to benchmark ourselves and understand where our site currently was. Our representative from the data team led this by running a session which had us all discuss different types of disabilities and how they might affect the way they use the web. He then checked to see if there was any way we tracked this. For the large part, the answer was no.
We then looked further, can we check to see what Chrome extensions are used? Do we know when someone zooms? Or increases text size? Again, we couldn’t track anything.
One thing that did come out of the analytics was a bit of data that showed how many rooms were searched for that included an accessible room. The majority of the time it was for more than one. This was fascinating as we’d previously been discussing factors that are very much to do with the design and code of the site, but with this fact our hypothesis was that many people who care for those with disabilities may be doing the booking. They don’t need accessibility features, they need accessibility information. They’re much more concerned with the width of a lift and whether a wheelchair will fit through it than being able to tab through content.
With the data looked at, we looked further afield and found Scope, a charity that aims to create equal rights for those with disabilities. The interesting thing about them is that they have a forum for people to discuss whatever their heart desires. And a quick search for “premier inn” brings up a few results — fantastic!
Reading through these posts certainly confirmed our theory on the need for information as well as build. We found that our room types were confusing, the design of our breakfast area isn’t suited to some people’s needs, and that the list of different needs is endless.
We would focus on the digital aspect but this gave us some arsenal to show the rest of the business who could impact change on areas where people are suffering.
This is the area that gave us the most insight and helped others to visualise why we’re doing this.
We used a remote testing tool so that we could get back videos of people using the web from across the country while they could be comfortable at home and use their own devices/tools. These are the participants we chose:
- Screen-reader user
- Screen-magnification user
- Keyboard-only user
- Speech-recognition user
- Dyslexic user
- Asperger’s or autistic user
These people were then asked to visit Premier Inn to make a booking based on a previous stay they had and visit a site that they would usually use to do the same. All the while they spoke about the positives and negatives of how their disability and assistive tools affected the way they interacted with the sites. The final question asked them to dream up their perfect experience.
What we learnt was incredible. There were very main parts of the journey that were completely inaccessible to certain assistive tools and methods of navigating the web. We had new insight on how images were used as those with dyslexia enjoy using them to understand features of a hotel more than trying to read about them. We also had good ideas on how to improve the experience.
Where this took us
Collating all of this information, I ran a presentation to the wider Digital team on what we had learnt and then ran a workshop on what we thought would be a good set of next steps.
This gave us a collaboratively made list of next steps which included training, changes in process, and more testing for UX, devs, and QA to conduct.
We also saw PO’s actively making this a priority by setting up workshops and asking UX to perform audits.
Due to this being new, it’ll require a lot of time to create the processes needed, upskilling of team members, and have people keep on top of everything to carry on pushing for it until it becomes routine. But, it’s definitely worth it.