Creating an Accessibility Program Requires Awareness and Empathy

Accessibility and inclusivity has been a hot topic for years, as enterprises around the world work to meet Web Content Accessibility Guidelines (WCAG) standards. They do this for legal, ethical and economic reasons, but there’s an often-overlooked positive outcome of working toward true inclusivity for your customers and your staff: making things better for one person benefits all.

In our recent webinar, Accessibility Now Means Less Pain Later, we highlight an Applause customer, Skyscanner, and their journey to accessibility, beginning with hiring a full-time employee to oversee organizational accessibility. In this blog, we call out key pieces of our full webinar in which Heather Hepburn, Accessibility Lead at Skyscanner, covers how she progressed Skyscanner’s accessibility efforts from awareness/understanding to education, executive buy-in, initiation of an accessibility plan and ongoing efforts. All with empathy at its core.

View the on-demand webinar here or continue reading excerpts from the conversation with our two speakers:

• Julia Zacharias - VP, EU Delivery & Customer Success, Applause

• Heather Hepburn - Accessibility Lead, Skyscanner

The transcript below has been edited for clarity and length.

Julia Zacharias: I'm very excited to be here today with Heather Hepburn from Skyscanner.

We're first going to do a short introduction and then cover some general definitions. Then we’ll discuss how to build a program to advance digital accessibility and inclusive design. And now I'm very happy to introduce you to Heather Hepburn from Skyscanner. Heather, please introduce yourself and what you do at Skyscanner and what Skyscanner does.

Heather Hepburn: Thank you so much for having me today. I'm excited to be here. I'm Heather. I'm the Accessibility Lead at Skyscanner. And for those of you who don't know Skyscanner, we are an online global travel brand. We provide flights, hotels, and car hire to our travelers.

We started up in Edinburgh back in 2003. And we now have eight offices around the world and about 1,200 staff. So, I have been on a mission to improve accessibility at Skyscanner for a few years now.

Zacharias: Thank you. My name is Julia Zacharias and I'm the Vice President for Solution Delivery and Testing Services for the European market at Applause.

We're the world leader in testing and digital quality. And as for Skyscanner and some of the other companies you are seeing here at the bottom, we carry out testing across all stages of the SDLC, always with the end goal in mind that we want to provide the best possible user experience for the end users of our customers. We have more than 1 million crowd testers across all countries with thousands of different devices that can test all the time, really fast, and help our companies release faster with more confidence and higher quality.

Digital accessibility baseline

Zacharias: Today we are talking about digital accessibility and inclusive design and some definitions and relevance. The important point I want to make is that digital accessibility is sort of a subset of inclusive design. And digital accessibility is really focused on digital products and services, with the end goal of making them accessible for the widest range possible of users, including persons with disabilities (PWD).

It's often measured with the internationally accepted WCAG. But they're not legally binding. They're just a collection of best practices for what to do to make your product accessible. But essentially, you cannot do that if you cannot, on the basic level, ensure that your product functions generally. That's where you should be starting out, then building the accessibility on top of that, also making sure the products and services comply with the established guidelines on the technical level. Then take it one step further and really strive for an inclusive design, a human-centric approach. That takes into account a much wider range of aspects that affect how people interact with the product, not just technical guidelines.

I would like to bring Heather back so we can hear what has sparked her interest in these topics and why she’s working in this field.

Hepburn: I started knowing about accessibility back a few years ago now when I was working for RBS. I was working in a team who were building a new online account opening system. I was a UX writer at the time and was just learning from them and including copy that would be used for screen readers, for example. We were just thinking about accessibility in our processes. And it just became very much naturally part of what we all did.

And then I left RBS and I was going through an interview process at Skyscanner for our UX writer role. I was asked to do a critique of their app. So over the weekend, I was looking at the app and trying to critique it from a UX perspective. And all of the issues I found were accessibility issues. I got the job and started at Skyscanner as a UX writer and just went on an accessibility mission from pretty much day one. From that point, it's been really important to me that when people talk about quality code, it's much more than just speed and availability and all of the things that developers tend to think. If your code is not accessible, how can someone describe it as high quality? Also, the exclusion elements, so many times you’re unknowingly excluding a whole group of users. I needed to do something about that.

Zacharias: Yes, and the case we also want to make is that, at some point in our lives, probably all of us will have some form of temporary disability, because that can be as simple as having a broken arm, so you cannot use your phone with your usual hand, or maybe you are holding a baby, or you have a sinus infection, so you are hard of hearing. So any of these are also disabilities, if only temporary. We’re all aging as well, and we often need more support around use of digital products and services.

To make it a bit more clear in terms of the kind of issues we're talking about when we're saying an application is not accessible, we see a lot of issues with screen readers — and this is something that companies that are first starting to address accessibility issues often deal with, since they often target users with low vision or blindness first. An example of a screen reader issue is when some kind of interactive element has not been assigned a name or role or a value, then the screen reader cannot pick it up. It might just say “button” instead of what the button does.

Color contrast issues are common too. For instance, if the text is light blue against the white background, it's hard or impossible to actually see and then understand the content.

European Accessibility Act

Zacharias: We want to look a little bit into the future as one more argument for change and why accessibility programs should be started now. And that's the legal argument. There's already lots of legislation implemented in other countries, especially in the United States and Canada. In the European Union, it's coming.

In June 2019, the EU parliament approved the European Accessibility Act (EAA) in order to remove barriers between the member states — because there was lots of different legislation in place — and make the internal market function better, with the end goal of ensuring that PWD and elderly people would have accessible products and services. This refers to everything, not just digital.

The good news is, at least from the legal standpoint, there's still three years until July 2025, when the EAA is being enforced for the products and services that are identified as most important for PWD and elderly people. But those are essentially all the services we use every day, so anything in banking, telecommunications, ebooks and the wide array of e-commerce etc. This means that for any organization doing business in the EU market, they must ensure that in the next three years they're making their digital and physical products accessible. This may seem like a long time, but it’s really not, as there is a lot to do when you start on a full accessibility program.

How Skyscanner started its accessibility program

Zacharias: The first step in starting an accessibility program is to raise awareness. So Heather, when and how did your journey for building a program begin, and who was involved?

Hepburn: So it was just after I joined. I found a Slack channel called the Accessibility Guild. I set up a meeting for people on the channel and about 30 people came to the first meetup. There were about 70 people on this channel back then and we’ve grown that to around 300 now. That was in March 2019 and we have been meeting up every month since.

Next, I went to our leadership to say, OK, look, I think we have some work to do here. It would be really nice to have a little bit of budget so I can employ some experts to come in and maybe do an audit to begin with and then also possibly do a workshop with us. That agreement was actually relatively easy to get, because I think as soon as you start explaining what we're doing, as in we're excluding people unknowingly, and then show an example of what we're doing wrong, everyone is very keen to understand more. So I was given a little bit of funding.

The first thing we did was audit our design system. So, I guess for people lucky enough to have a design system, it's a brilliant place to start. Because if you can have accessible components and if you have a system that gives guidance on accessibility, you're halfway there. In fact, you're more than halfway there.

I wanted to understand how accessible our components were. So we did an audit on that. I also started working closely with a new project building our new mobile website. It was still in the early stages. We started there with the idea of learning and then perhaps scaling across other products. It was perfect to start small, and it’s all grown from there. And it’s just me in this permanent accessibility role, but we have a network of accessibility champions now, so that’s a big help.

Zacharias: So awareness is first and then what did you do next?

Hepburn: Raising awareness has been my main aim over the last couple of years. Training was next. I first started talking to designers because I felt that nothing was ever going to be accessible unless it was built in from that early stage in the whole process. So getting accessibility considered from as far left as you possibly can is key. Much of this training was talking about different types of disability: the permanent disabilities and temporary, the ones that affect us all everyday just in the situations that we're in. I think this is a big realization for people and draws them in.

Next, I would talk about how to design and build in an accessible way. From that, I built a Skyscanner Uni course and then we built a Skyscanner University tool that anyone can upload a course to. We also did a project where we looked at our own accessibility for our internal staff. We got a lot of great learning from that. We did some other workshops, like one with AbilityNet on how to use screen readers. These workshops were very hands-on. This is important when it comes to people learning and gaining empathy.

Overall, we do lots of communication; we write lots of blogs, do social media, invite people to come speak to us, and we focus on accessibility for our products and for our internal staff as well. It’s an on-going process. And on the technical side, we run a weekly automated audit now on our website and our mobile website, and we continue to see regular progress there, but still have a lot more to do.

Empathy labs

Testing with people with disabilities is absolutely the best thing to do. It is fascinating to see how people interact with your product. And it can be in ways that you would never imagine. I think that is a really good thing to do when you're trying to get backing from leadership. Show someone struggling. Nobody wants to see that. And you can just do a little bit of testing with someone, record it, and share it. That's been powerful for us.

Related, I’d like to mention the empathy labs that we've run. We’ve done a few of these. We get everyone to come in and experience disability for themselves. These labs are places where we simulate different disabilities. And we have set up a lot of technology there. So we've got laptops around the room. We've got phones. We've even got a dart board. And the idea is that our Skyscanner employees can sit down and really see things from a different viewpoint, be in someone else's shoes that they might not have ever considered before. This plays out then in how we design our products as well as how we make things more accessible for our staff. [See the replay of the webinar for a video overview of an empathy lab.]

We have a small working group of accessibility champions that helps organize these labs. It’s very impactful. We have, for example, a station where people try to open a jar while wearing arthritis gloves. These types of things. These really create lightbulb moments for people.

Progressing the accessibility project

Zacharias: Fantastic. Let's move one step more now in the program. You created this awareness. People really want to do it. Maybe you've run your first audit. You kind of know where you are and what you need to fix. And the question is, obviously, where do you go from here?

Hepburn: The hardest part, in my opinion, is getting accessibility embedded into all of your processes. And we are still not 100% there yet by any means. In our requirements documents at the beginning of a project, there are accessibility requirements as a section. And I guess it's in some people's project plans, but not everybody's. So that's my challenge at the moment to get it across the board. But it's really, really nice if things are considered even before a designer is involved so that it's at least there and it can be considered then when it moves on a stage. For the designers, it’s been mainly around raising that awareness, particularly around things like color and layout and font. So I feel that's in a good place.

We've created a set of accessibility annotations in Figma. So when a designer is creating a design spec to hand to the development team, they can mark up their designs with accessibility information. And that has made such a difference.

We started simply. At the moment, we've only got four different annotations, just one to mark up headings, one to mark up focus order, accessibility text - which can be anything from Alt text or ARIA labels, or anything to do with screen readers - and grouping, so when anything on a page should be read out in one go by a screen reader, but it might visually not look like that, we've got a grouping element as well.

And these are readily available in the Figma community that we borrowed, I think it was from Twitter's set of guidelines. And yes, there's loads of them out there. And we just made them work for us. I wrote some guidance on them and rolled that out to the design team.

And then, I guess, the design system, again, having accessibility embedded into our components and guidance alongside it. We're actually working on that just now. We're redoing our design systems, called Backpack. And it will be available so everyone can get in there and have a look at it. But we have an accessibility consultant who's helping us create all the component-level guidance and just making sure that all our components are properly accessible.

And in the testing phase, we have developers involved. We don't have QA in house, so we use Applause for testing, but our developers test each other's work as well. So again, it's about awareness and knowing what different tools we can use there too.

We're rolling out a tool called Cypress Axe, which has an element of accessibility testing within it. And once we get that rolled across all of our development teams, that will be a great way to catch anything that's still a problem. Developers should also be doing it at the unit testing stage to make sure that everything is good before it even gets to that end point. So there's so much to do.

Summary of key success factors

Zacharias: Let's wrap up the key success factors and the phases again for building this program. So we spent a lot of time on the first phase, understanding/awareness and committing to it, because it seems if you do that right, the rest is easier. As soon as everyone understands why it is a problem and how it feels, it becomes much easier to do everything else.

Next, communicate the vision on where you want to go. Then understand where you are with an audit. Where do you stand when you check the WCAG? Then work on executive sponsorship in your organization. That's where the technical phase starts, really doing the changes, providing these trainings that you talked about to your organization, having everyone try their own apps using a screen reader and other accessibility features, not just the design and development teams. You pointed out, you also involve, for instance, HR for also the internal processes, not just for the customers.

If possible, involve PWD in research and, later, testing. Generate and celebrate some quick wins. Keep innovating and improving, because that is not a one-time effort. It's really a long-term program that requires a lot of change management thinking. It’s not just the technical part, like teaching people how to develop accessible code, but also why to do it and then continuously improve on where you are. I know this is a very high-level summary.

One last question, what is your team’s success criteria?

Hepburn: You summarized that really well. That is exactly what people have to do. I think things really change when someone is made responsible for accessibility. There are a lot of companies out there with maybe small networks of interested people who are trying to do the right thing. But it doesn't seem to really start motoring properly until someone has the responsibility of making it happen. Also, developing champions is really key, as I’ve said earlier. You can’t do it alone.

Finally, embed accessibility and inclusive design as far left in the SDLC as you can.

The sooner you start, the better

Zacharias: We recommend that firms start now with all of this. There is the legislation part, but beyond that, it's the right thing to do and it concerns all of us. It will make your products and services better for all users. It's a good argument from all perspectives, the moral one, the legal one, the financial one.

Change management is a big piece of this, because this program is not just about the technical side. It's really about also capturing people's hearts and heads and then moving this along.