Improving the accessibility for two major airlines

KLM Royal Dutch Airlines is the flag carrier airline of The Netherlands, and the oldest airline in the world still operating under its original name.

Over a two years I worked on many projects and digital touchpoints, from creating an Android Sketch library for the mobile team, through to designing the first iterations of the ‘My Trip’ page for the BlueWeb website project, a combined website for Air France and KLM.

A substantial part of my work was focusing on improving the experience for persons with disabilities when interacting with the customer-facing digital touchpoints, mobile, web, and kiosk.

An annotated screenshot, showing where improvements could be made

Client: KLM & Air France
Platform: Website, iOS, Android, Kiosk
Role: Senior User Experience Designer & Accessibility Consultant
Date: 2019

The objective

My assignment for 2019 was to make improvements across the customer-facing touchpoints, primarily for people with disabilities.

After assessing the state of the Blueweb website (a combined website for Air France & KLM), the primary iOS and Android apps, and the kiosk, it became clear that there was a lot of work required.

I split my goals across several themes:

• Increase internal knowledge — The understanding of accessibility was limited throughout the organisation, with designs lacking accessibility considerations, leading to either poor implementation, or an experience that simply would not work.
• Get buy-in — Accessibility tickets were logged and living in the backlog, I needed to increase the visibility of accessibility in the organisation, and ensure accessibility was added to the definition of done.
• Review the current projects — The iOS app, website, kiosk, and other smaller projects, such as the online boarding pass, needed to be reviewed, to see where the major issues were. As a User Experience Designer, my focus was not purely on conformance, but also the experience.
• Improve the designs — Consulting, and mentoring were my main objectives, but I also wanted to help improve the designs myself.

The process

Before deep-diving into one of the projects I tackled, I want to touch on a few things that were necessary to ensure the proposed improvements would not simply be added to the backlog.

There were noticeable knowledge gaps throughout design, development, and QA. Accessibility was often only considered during the testing phase, this led to many problems.

Where accessibility was often considered

When accessibility is only considered at the end of the project, then solutions are often retrofitted at the earliest possible stage. So for example, if something did not work for a keyboard user, then it would likely shift left to the developers to retrofit a solution, which often leads to overhead that would have been unnecessary if it was coded correctly.

Accessibility shifting left to the development phase

Some issues need to shift even further and go back to the design team, this leads to the designers having to change elements within their design solution before handing back to the developers to implement.

Accessibility shifting left to the design phase

Worse is when a design is simply too costly to retrofit accessibility in, which results in the design teams having to go back to the drawing board to try and sketch out solutions which will work for the audience.

Accessibility shifting left all the way to the start

Ultimately, accessibility needs to be considered before a pencil hits a notepad. This leads to better design solutions and leaner, more semantic code…

Where accessibility should be considered

I knew that as an individual I would not be able to spend time across all of the areas of design, development, and testing, so I wanted to spend the time I had with the Air France and KLM design teams.

Increasing internal knowledge

Over the year, I ran six workshops, these workshops were primarily for (UX) designers, but they were also attended by visual designers, writers, product owners and front-end developers.

One of the workshop exercises

The goal of the workshop was to increase the awareness of those primarily involved in designing the experience for the users. The half-day workshops introduced the topic, introduced personas who often experienced barriers on the web, and had numerous exercises throughout.

A designer wearing Cambridge simulation glasses

Simulation exercises are to be used with caution. As a hired consultant I have restrictions with what I can do, so I always carefully frame these exercises.

“Impairment simulation cannot convey what it is like to live with a capacity loss on an everyday basis, so all simulations that we do today are not intended for us to conclude how this lived experience is. The intention is to help us design more inclusively by taking into consideration others needs that we may not be as familiar with.”

The workshops ended with a sketching exercise, which introduced a common problem that the team was facing. They would then consider all of the people that we had spoken about, and all of the barriers that they faced, and then had to sketch out solutions which would remove some of those barriers.

Sketching exercise

Training and workshops

Get buy-in

It is great to see accessibility bugs already logged in JIRA, but when you see the date they were logged then it can cause some concern!

To avoid creating bugs that would live in a backlog, I knew that I had to get buy-in from people further up the food chain. Although generalising, there are some approaches that I find work better than others, within business roles.

• Design — Empathy is a word thrown about a lot in design, but often I find designers want to do something because it is the right thing to do. For those in brand, hearing about the improvement of brand perception also helps.

“Who are you? What do you do? Why does it matter?”― Marty Neumeier, The Brand Gap

• Business — People who deal with money, need to talk money, whether it is cost-saving or revenue-increasing.

“The Commission has urged businesses to do more to value and serve the ‘purple pound’- an estimated £212 billion market.” — UK Department of Work and Pensions

• Legal — The legal departments want to talk about risk. What happens if we don’t make our website, or product, accessible?

Slide from a presentation I gave to the Legal department

I presented to the different areas of business and made some new allies. One, in particular, helped push accessibility into focus, and dedicated time was committed to solve some of the bugs, and to tackle the new ones…

Review the current projects

The Blueweb project is split into various teams, and these teams tackle a particular area of the website. So for instance, one team is in charge of ‘Search’, and another team is in charge of ‘Check-out’.

Although a design system was in place, it often lagged what the teams needed at that time. This led to some components being accessible in one place, and not in another.

So, I needed to be aware of the following:

• Testing the team output — I performed automatic, and manual checks on the various sections of the website. I logged tickets relating to WCAG failures, and also accessibility improvements into JIRA. These tickets sometimes needed more support, such as an annotated screenshot, to help the developer understand the issue and offer ways in which to solve the problem. I also presented the key issues to the team, so they can get an understanding as to how this may create a barrier to some users.
• Testing the flow — Teams may create areas of the website, but customers only care about the flow, can I book a seat? can I get information on a previous booking? These questions take the user through various screens, which live in different teams. By testing the flow I was able to check to see whether the customer was having a consistent experience, or not.
• Stop design system leakages — When an accessible component was designed and implemented on a team level, then it needed to feed back into the component library. This was something I intended to focus on for 2020 (until Coronavirus hit!), the goal was to have one source of truth, and to avoid rogue (inaccessible) components living in the wild.

A page template inside of the component library

Accessibility consultancy

Improve the designs

There were many ‘wins’, including an improved seat map, and how disabled buttons are now ‘visible’ to screen reader users, but I will share one particular improvement — the login experience.

To improve the login experience for the website I tested the current implementation, researched other methods, presented the findings, and proposed an improved solution which was not only more logical but also greatly improved the experience for keyboard users.

On first glance, the login screen may seem well designed, but after exploring the page with a keyboard (and a screen reader, as shown in the following video), it was clear to see that there were some issues regarding the logical ordering of elements.

The tab order for keyboard users was:

1. Please enter your Flying Blue number or e-mail address
2. Forgot your Flying Blue number?
3. Please enter your Password
4. View password
5. Forgot your password?
6. Protected by CAPTCHA Group
7. Privacy
8. Terms
9. Login
10. Cancel
11. button
12. button
13. button
14. button
15. button
16. Don’t have an account yet? Sign up now

The old login screen with the tab order highlighted

Skipping over the obvious issues with buttons, it is clear to see that there are problems with the grouping of objects, to highlight this I broke things down into the tasks the user would want to complete.

1. Log in — The primary task of the user
2. Recover credentials — If a password or Flying Blue number is forgotten then the user needs to quickly and easily retrieve it
3. Sign-up — As there is a separate link to sign up in the page header, this does not need to be as prominent on this particular page.

To complete the primary task, a keyboard user would need to move to the 1st, 3rd and 9th tab stops.

To log in through alternative means, a keyboard user would need to move to the 11th, 12th, 13th or 14th tab stop.

To recover credentials, a keyboard user would need to either tab to the 2nd or 5th tab stop.

Although there are some issues on Mailchimp, the largest being that the ‘Show’ button is not accessible for keyboard users. The login form is much more task-focused.

1. Create an account
2. Username
3. Password
4. Login
5. Keep me logged in
6. Forgot username?
7. Forgot password?

The proposed wireframe with better grouping of tasks

By focusing on the tasks of the user, I re-designed the login form, which made the process easier for keyboard (and screen reader) users.

To complete the primary task, a keyboard user would now need to move to the 1st, 2nd, and 3rd tab stops.

To log in through alternative means, a keyboard user would need to move to the 6th, 7th, or 8th tab stop.

To recover credentials, a keyboard user would need to move to the 4th or 5th tab stop.

The finished login screen

There were a few smaller battles that I did not win in the end, but the result was still a much better experience than before.

User Experience Design

Results

The results were very positive, hearing conversations about accessibility happening when you aren’t involved is a good sign!

“He is one of the few designers that really changed my perspective on how I create my digital solutions, and especially for whom I do so.” — Teun van den Braber, UX Designer, KLM

Accessibility was added to the ‘definition of done’, the internal knowledge in the design team grew, although there is still work to be done in other areas, several new advocates appeared, and many items were taken from the backlog and closed.

Oh, and there was also this…