The case for accessibility

by Laura Carvajal

Published in

FT Product & Technology

7 min readOct 21, 2016

At the Financial Times we’ve recently released a new version of our website, FT.com. “Next FT”, as we’ve come to know it, is now the default experience for our users, and so far it’s proving to be a great one: It’s faster, it’s nicer, it’s better; a success across the board [1][2]. Yet there’s an aspect of our new site we have largely overlooked: accessibility (a11y).

[caption id=”attachment_8939" align=”aligncenter” width=”840"]

The new FT.com[/caption]

In this post we will explore what web accessibility is, why it’s important, the current state of accessibility at FT.com and the work we’re doing to improve it.

This will be the first of a series of posts that will document our progress on web accessibility at FT.com.

What is a11y, who is it for and why should we care?

In general terms, something is accessible when it’s easy to approach, reach and use. This definition can be applied directly to anything we build, including websites.

Web accessibility normally focuses on ensuring people with disabilities can have easy access to the same information as everyone else. This seems like a fair assumption, but building a website that is accessible is not only fair, it’s the law, and failing to do so is a form of discrimination [3].

Accessibility also benefits people without disabilities in certain situations, such as people using a slow Internet connection, people with “temporary disabilities” such as a broken arm, and people with changing abilities due to aging [4][5].

The image below shows a comment from one of our subscribers (posted to one of our Slack channels by FT Customer Research Executive Maria Pachaki) which exemplifies the impact of low accessibility beyond disabled users.

[caption id=”attachment_8941" align=”alignnone” width=”840"]

Subscriber feedback on accessibility[/caption]

So, with this in mind we decided to take a closer look at FT.com to determine the state of our accessibility.

Accessibility efforts at the Financial Times

As we make the case for accessibility at FT.com, it’s worth noting that there have long been accessibility efforts within our technology department. Teams, as well as individuals have made important contributions towards accessibility. One such team is Origami, which, among other responsibilities, maintains a repository of components used in FT.com and other FT sites. These components have high accessibility standards that are enforced and automated. But Origami can only go so far. The teams responsible for building the websites, like Next in the case of FT.com, need to make sure those sites live up to the same accessibility standards as the components they use.

Due to the nature of our architecture, where smaller services make up the whole of our site (front page, article page, myFT, etc.), and each of those services is managed by different sub-teams within Next, the responsibility of guaranteeing the accessibility of FT.com as a whole is fragmented and uneven.

So, just how bad is it? A closer look at FT.com

One obvious way to determine the level of accessibility of FT.com would be to get feedback from real-world users who access the site through various assistive devices. This is a very desirable scenario, once we know roughly what we’re asking our users to test.

In Next, we know FT.com inside and out and we have user groups test it on a regular basis, but do we actually know what our site feels like when it’s used through assistive devices? The answer is we don’t, at least collectively, because accessibility is something we don’t evaluate formally nor have considered a part of our development process. Yet.

Another approach that better suited our current situation was to evaluate FT.com against the Web Content Accessibility Guidelines, or WCAG [6], which provide a set of principles or success criteria to evaluate web accessibility. A first look at their quick reference checklist [7] revealed that our most prominent markup violated several of their recommendations. This led us to conduct a full audit of every user-facing app in our ecosystem. While it may sound daunting, and an ad-hoc manual audit could certainly be, automated accessibility check tools, coupled with our fluid continuous integration process, made this task quick and straightforward.

The following example shows how, with very little effort, our apps integrated WCAG accessibility checks using Pa11y. This gave us the visibility we were looking for into what and where our errors are, while setting the stage for preventing future errors from entering our codebase and ultimately improving accessibility.

Step 1: Find the bad errors. Fix them.

FT.com is made up of multiple apps of very similar structure. We will have a look at our article app, next-article, which serves article pages such as this one, to illustrate the process.

Enter Pa11y

Pa11y is an open-source set of tools designed to monitor website accessibility. It is clear in stating that it “can’t catch all accessibility errors. It’ll detect many of them, but you should be manually testing (ideally with users) as well” [8], but it provides a baseline by pointing out clear accessibility violations.

In short, Pa11y runs on a list of URLs and evaluates them against the guidelines of our choosing, defaulting to WCAG2AA [9]. Each project provides a list of URLs to test of in a .pa11yci.js file:

[caption id=”attachment_8943" align=”alignnone” width=”840"]

pa11y-ci configuration file[/caption]

These checks were integrated into our CI process using pa11y-ci, guaranteeing they run on every build of every branch, before release.

[caption id=”attachment_8948" align=”alignnone” width=”840"]

pa11y-ci running on a branch of next-article. Errors are detected.[/caption]

To avoid disrupting development pa11y-ci was initially integrated ‘silently’ into all our apps, meaning that it reported errors but it didn’t prevent builds from passing (see green build above). To do so, we used the following setup:

[caption id=”attachment_8946" align=”alignnone” width=”840"]

pa11y-ci runs on the article test app on every branch[/caption]

This allowed our teams to become aware of the errors and to start fixing them in parallel with ongoing development. Once all errors were fixed, the threshold (-T) parameter was removed, which meant any new errors would now break the build and prevent that branch from being merged to master and released to users.

At the time of this writing, around 60% of our apps no longer use the -T option, with the rest of them scheduled to follow suit before October 31st. Some have already caught and prevented what would have been new a11y errors on our site:

[caption id=”attachment_8942" align=”alignnone” width=”840"]

pa11y-ci picks up a new a11y error in CI. Devs go wild.

pa11y prevents an error in CI. Devs go wild.[/caption]

So, that fixes it, right?
We’ve made Accessibility Great Again

Not quite. Having 100% of our markup pass every pa11y check will be just the beginning. Automated tests can tell us when something is obviously broken, like an <img> missing the alt attribute, but it will be quite content with markup that is correct but meaningless, like <img alt=”foo”>.

Pa11y prevents us from making things worse. It’s up to us to make them better.

So, what next?

As we can see, ensuring the accessibility of our website is hardly a one-off effort. Over the course of the coming months we will continue our efforts to improve accessibility at FT.com by building on the foundation that Pa11y has provided.

Here’s a bird’s eye view of what lies ahead:

Check that we comply with basic WCAG. Automate those checks on every user-facing app, but don’t break builds. Done!
Enforce it everywhere. “Break the build”. No more new a11y errors.
Spread the word. Make a11y a part of how we reason about our work. Learn from accessibility efforts elsewhere.
Test it. Now we have a better idea of what we have. Show it to real users to get their feedback.
Fix problems. Make it better. Learn some more.
Integrate it into our dev and QA process. Implement an input/output device matrix and apply it.
Collaborate beyond Next with teams whose markup is also part of FT.com, such as Editorial and Origami.
Continuously monitor and improve. Don’t settle. Keep learning.