Power to your people: Working to make Pleo more accessible

Technology makes so many things easier in modern life.

And for people with disabilities, technology has the potential to take the impossible and make it possible.

Accessibility is all about making content available to as wide an audience as you can – in our case, by designing and developing flexible, high quality solutions.

That’s no matter what somebody’s abilities might be, or how they might prefer to access content.

Pleo and accessibility

Here’s the truth: We haven’t been superstars in this arena. There are explanations for this of course, although they’re not excuses.

Small companies have limited resources and if they’re to survive in competitive industries, they need to be strategic about how they focus their energy.

With tech companies, there’s another consideration.

Developing highly accessible solutions hasn’t, historically, been an integrated part of the designer / developer curriculum.

Taking a new approach

For us, this very imperfect situation changed last year.

In November 2020, our Design team dedicated an entire week to digging into accessibility and we, as an organisation, decided to take an active stance on the subject.

What I’d love to do now is fill you in on the background, the work we’ve done so far and what we’ve learned along the way.

The background

Star Trek’s Spock famously said, "The needs of the many outweigh the needs of the few."
He's probably not the first person (or Vulcan) to have said something along these lines and in business, it’s a common sentiment.

Across a range of issues, we're a company that caters to and depends largely on "the many", not "the few".

Do we prioritise "the many", skimping on accessibility so that we can ship more features faster? Or do we make it our mission to build highly accessible software, shipping fewer features at a slower pace?

We are a business, of course. But that business is composed of caring individuals, who believe that everyone can and should be met with understanding and empathy.

In this context, we’ve come to see that it’s too simplistic to adopt that "many" vs "few" mindset. And the research backs that up.

In the UK alone, it’s estimated that seven million people of working age have a disability. The so-called "purple pound" is worth £249bn to the economy.

That puts a sharp point on the dilemma that we, and many other tech companies, have wrestled with.

We've now identified the way forward and it's quite simple.

A better product for everyone

Spock travels around in a spaceship, warping to different planets and galaxies, battling aliens and living a rather dramatic existence.

We build and sell company spend software to make your life managing company expenses a whole lot easier. We aren't being hunted by Klingons and going on perilous adventures, so we don't need to be as drastic in our presumptions as Spock is.

Frankly, we needed to discard the idea of “the few” – and start thinking about everyone. Because accessibility affects us all.

So how does this work in practice?

The Pleo product is built and maintained by feature teams that have historically enjoyed a high level of autonomy and been extremely effective at pushing out contained features at pretty dazzling speeds.

That worked well for a period.

Autonomy is great, but if we’re all solving unique problems without relating them to the broader picture, we end up pulling and pushing the fabric of our software in unintended directions.

This, coupled with differing skillsets, personalities, goals and experience within the feature teams, can lead to some substantial deviations in the overall code base that transcend to the user interface... which is exactly where accessibility lives.

The approach

Let me start this section with a confession. Our product is nowhere near as accessible as we want it to be.

But the path has been paved and we are on our way.

We’ve been following the following process:

1) audit the platform

2) fix obvious accessibility flaws

3) map out the most important user flows

4) make these navigable through alternative or assistive tech (keyboard, screenreaders, etc.)

5) test with people who rely on said technologies

6) iterate and optimise if needed

Where are we at? We're currently somewhere between step 3) and 4) for our web applications and we're slowly getting started on our mobile applications.

Pleo has three main customer-facing platforms: our commercial website, our web application and our mobile application.

All of these platforms have to have a high degree of accessibility if we're to create a solid user experience for individuals who rely on assistive tech or who have specific preferences on how they consume content or solve digital tasks.

So, if you're able to onboard to the product, but not use it? We've failed.

If onboarding isn't highly accessible, but the application is? You'll never know, will you? So we will have failed there too.

That's why we have to consider the entire Pleo portfolio when working with accessibility.

How do we audit? For web-based solutions, auditing tools are readily available. We've been using Chrome Lighthouse, ChromeLens and Axe to sniff out accessibility blunders and fix them in our main product. We aim to do the same for our commercial site and are currently looking into auditing tools for our mobile application.

How do we prioritise? We start by ensuring that the main components in our user interfaces are of a high quality and that they meet stringent accessibility criteria. If the building blocks are lacking, the construction will be lacking.

If a certain flow (let's say changing your profile information) is built with non-accessible components, you won't be able to explore that flow. Therefore the components must, as a minimum, be built to mirror accessible web standards, be navigable by keyboard, have sufficient contrast ratios and have logical interaction patterns.

What's the strategy? It's no secret that focusing more on accessibility will affect the speed at which we can develop new features to some extent, especially at the start. But, by ensuring that the most important functionalities are accessible by assistive tech, we set a strong point of departure for future work.

This basically means determining what should be a feasible user journey, determined individually for the solutions that customers interact with.

Who owns what? Every team that contributes to the product should know about accessibility. However, skillsets and experience differ, so there is a need for clear ownership.

The DesignOps team at Pleo ensures that every component served from our Telescope Design System is highly-accessible and built with correct semantics. We champion accessibility and assist/encourage other teams to build components to those standards.

How do we maintain high standards? A strong focus on accessibility from the conception of a component to its launch helps us ensure that accessibility isn't just an arbitrary afterthought.

From a programmatic point of view, we can ensure quality by implementing code checks, accessibility tests and audits during development and build for the different solutions. From a human point of view, we listen to our customers when they meet walls and we figure out how to help them overcome them.

What’s next? We've started a journey towards building more accessible applications at Pleo.

We aren't there yet, but we are dedicated to making our applications accessible for everyone within the near future.

All of our teams know that accessibility is important. We need to focus on improving it, not just because it makes sense from a business point of view, but also because it's the right thing to do.

This blog post isn’t here to trumpet our achievements so far. It’s to keep us honest – when we read these words back in six months, or a year, or five years, we want to be proud of the progress we’ve made on accessibility. It is, as Spock, might say, only logical.

Have you noticed any accessibility issues in our application that hinder you or one of your colleagues?

If so, please reach out to me (allan@pleo.io) and we'll take it from there.