Why Passenger cares about accessibility

At Passenger, we are dedicated to accessibility. In 2016/17, 13.9 million people reported a disability – that’s over one in five of the overall population and a considerable step up from the 11.9 million people (19%) reported in 2013/14.

Of that number, almost 2 million people are blind, a number estimated to double by 2050. There are also an estimated 9 million deaf or partially deaf people in the UK.

Accessibility is not a ‘nice-to-have’ feature but an absolute necessity.

The inclusive transport strategy comes from the Department for Transport, and aims to achieve equal access for disabled people by 2030. Public transport connects people to family, friends and work and should be easily accessible from journey planning, bus stops and bus travel. In recent years, smartphone apps have rocketed in popularity as a way to share this information with passengers in real-time.

Common disabilities that can affect a person’s use of an app include blindness or low vision, colour blindness, deafness or impaired hearing, dyslexia and restricted motor skills. Apps must consider and cater to all people living with these conditions. That means considering every element of the user interface (UI), readability, navigation, content organisation, use of colour and more besides.

It may seem like a lot, but making apps accessible doesn’t actually require extensive code restructuring. By and large, it means working through the subtle details of how users interact with your app and making incremental updates in response – not making sweeping, feature-breaking changes.

Here are some of the considerations we keep front of mind at Passenger and work to reflect in our apps as much as possible.

Words and typography

There are multiple considerations that we make when creating and presenting text.

We keep content and accessibility text short, succinct and to the point, with a simple and consistent vocabulary. Not only does this make it easier to understand, but screen reader customers hear every UI element read aloud. The shorter the text, the faster these customers can navigate it.

We use action verbs to indicate what an element or link does, not what it looks like, so a visually impaired person can understand (e.g. “buy” not “click here”). We also do not tell users how to physically interact with a control (e.g. “click here”) as they may be navigating using a number of different devices. (Keyboards in Passenger also support completion via iOS voice input, meaning users can voice audio commands rather than manually inputting them with the keyboard.)

To improve readability, we reduce the use of serif/italic fonts and ensure uniform spacing between words. We choose typefaces that are clean with fairly even letter widths. This allows for consistent, predictable layouts, even where the app content itself is dynamic.

We also allow text size to be increased using an operating system’s settings. Passenger follows the Web Content Accessibility Guidelines (WCAG) 2.0 for the text sizes in its apps. We also use a large line height to make text as clear and readable as possible.

Colour and contrast ratios

At Passenger we fully believe that accessibility and company branding are not mutually exclusive: you can incorporate assistive features without compromising brand aesthetics.

Passenger also follows the Web Content Accessibility Guidelines (WCAG) 2.0 colours and contrast ratios featured in its products.

We ensure that the primary, secondary and accent colour that we use across our apps support usability for those with low vision. That means using varied, distinguishable colours with high contrast between foreground and background. When we create a new theme for an operator (using the colours based on their brand), we aim to make all contrast ratios for text pass the WCAG AA standard (min. 3.1:1).

It’s important to provide useful and descriptive labels that explain the meaning and purpose of each interactive element to users. We make sure that cues other than colour are used to distinguish UI elements – such as written labels and error messages. These extra design elements ensure that users who are colour blind are able to receive the same amount of information as other users. These labels also allow screen readers to explain the function of a particular control to users who rely on these services.

Layout

When working with layout, every button, image and line of text added can increase the complexity of a UI. That’s why we consider accessibility from the first stages of design.

Layout considerations include minimising the amount of elements we show on screen, ensuring what we do show is clearly visible and delineated, making sure key information is discernible at a glance and implementing a clear hierarchy of importance (input focus follows the order of the visual layout, from the top to the bottom of the screen).

For instance, for Passenger apps that have digital ticketing, we have implemented a feature that automatically places recently purchased ticket products at the top of the ticket purchase screen. This removes the need for users to navigate through ticket categories to find their most commonly purchased products. This can significantly reduce the interaction/complexity required to ‘renew’ a ticket ahead of travelling.

We also ensure our layouts are flexible and responsive. This means that they automatically adapt to the size and format of the screen on which they are being viewed, whether that is a desktop, mobile or tablet device. This makes for a clear, accessible viewing experience whatever device or platform is being used.

Alternative text

All content images on Passenger websites include alternative text for screen readers where there are not already captions. Decorative or non-useful images that provide no practical context do not include alternative text, as this can lead to confusion rather than clarity. We have published a guide on making images accessible in our customer Help Desk, which aims to support content editors in their responsibilities around universal usability.

Grouping content

Keeping related items in proximity to one another is useful for those who have low vision or have trouble focusing on the screen. We always attempt to arrange related content into groups so that accessibility services pick up the content in a way that reflects its relevant groupers. This way, users of assistive technology don’t need to swipe, scan or wait unnecessarily in order to discover all information contained on the screen.

Where HTML elements do not already provide context, ARIA labels, or navigation landmarks, provide a way to identify groups or lists of links that are intended to be used for website or page content navigation in Passenger, thus making those links more easily identifiable and accessible.

Navigation

We ensure that Passenger product task flows are clear, contain minimal steps and that the navigation controls to commence the flows are easy to locate and clearly written.

For instance, the “Skip to content” link on Passenger websites enable users to get to the information they need quickly and easily, as it means keyboard and screen readers do not need to navigate a long list of elements before arriving at the main content. This is particularly difficult for users with some forms of motor disabilities.

We try to avoid using hidden gestures for actions (e.g. swipe to delete). Using always visible buttons, icons and text make the interface easier for users to interpret and requires less operating system specific knowledge.

We also avoid having UI elements that fade out or disappear after a certain amount of time.

Buttons & touch targets

Buttons and touch targets are the parts of the screen that respond to user input. We make sure that they’re large enough to accommodate a large spectrum of users, are highly visible and are separated from other content to ensure balanced information density and usability.

The baseline text size for buttons and links in Passenger products is set to 14pt bold, which by the WCAG standard is classed as large text.

Testing

We test all new products and features extensively to ensure screen reading works and that background text/colour combinations are effective. No Passenger product goes out the door without these processes first being carried out.

While we have made many accessibility changes in response to feedback received via the Passenger apps themselves, and sometimes via an operator, we have not yet completed controlled testing directly with disabled users – e.g. invited blind users to work with us to review the whole Passenger app, or perform specific functions within it. As our team grows, we plan to engage further with our users in 2019 to gain feedback from people with disabilities and better learn how to make our solutions more accessible.

Would you like to learn more about making apps accessible? Please get in touch with us. We’d love to hear any feedback or suggestions that you may have.