An outbreak of Accessibility anti-patterns
By Chris Gathercole, Patricia Ofuono, Mehmet Duran & Georgie Murray
Recently, the Digital Accessibility Centre (a group who works with clients, such as the FT, to create digital media that is accessible to all members of a population) conducted their annual audit of FT.com. Despite FT.com running an extensive pro-accessibility initiative the year before, their report detailed issues such as missing ALT texts and disappearing logos, which was making life difficult for users of screen readers, or those in need of high contrast displays. Within two weeks, a Rapid Action Team (comprising representatives from Development, Design, PM, and PO) was spun up, assorted issues diagnosed and converted into post-its (yes, we do Agile), three days of concentrated dev and design work, deployment, and the FT.com site’s accessibility certificate was approved for another year.
So what were those accessibility issues which had re-appeared despite our best efforts, and why, and why do we care?
Starting with “Accessibility: Why do we care?”
Accessibility refers to the design of products, devices, services, or environments for people who experience disabilities.
The concept of accessible design and practice of accessible development ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers).
Accessibility is one of our key product tenets which began its journey into the FT development lifecycle from a developer initiative, following an exercise called Acceleration Month, in 2016, where project proposals were made, voted for and implemented by self-formed teams.
An agency, Digital Accessibility Centre (DAC), was invited in to do an accessibility audit of ft.com. They gave a presentation on how accessibility (or, more importantly, the lack of it) actually affects people. This had a lasting impact on the FT teams, and accessibility as a concept has become embedded in our design and development processes on the FT.com site.
Accessibility is becoming a significant criteria for some US government contracts, as part of Section 508.
Accessibility best practice is simply good UXD, of benefit to most users, including folk who really should switch to bifocals or have simply wandered outside on a sunny day and need a high contrast display.
Some Sneaky Accessibility Anti-Patterns
An anti-pattern is “a common response to a recurring problem that is usually ineffective and risks being highly counterproductive” (Wikipedia).
The accessibility audit flushed out these anti-patterns:
- User paths which get stuck in loops
- Awkward tabbing sequences for screen readers
- GIFs without pause buttons
- Lots of ALT text missing (i.e., text which can be read by a screen reader, describing the content of the image, or might be displayed if the image itself has failed to display) for example:
- Videos with autoplay and non-stoppable pre-roll ads. The user receives no warning/info about what is happening, tries to stop it and cannot
- Some FT.com pages had heading order problems
- When a user inverts the site colours using Windows High Contrast mode (for example due to sensitivity to brightness or colour blindness) logos in the masthead and some iconography across the site disappear.
How did these Accessibility Anti-Patterns sneak in?
It is fair to say that many more accessibility anti-patterns did NOT sneak in because of the good work carried out in the previous year. There is automated testing, e.g. using Pa11y. Many of the development teams took the accessibility mindset to heart and have been vigilant. The FT’s Origami team (origami.ft.com) acts as a gatekeeper on new site components, demanding accessibility as one of the entry criteria.
Automated tests are good at catching the simple, well defined, known issues, such as:
- Small text
- Poor colour contrast between text and background
- Images missing ALT tags
- Page headings missing or not in logical order
- Main elements of page missing, such as title, or language of the page
… but automated tests do not generalise beyond the very specific instances they were originally designed to spot.
Some issues are very subjective and nuanced, e.g.,
- Looping user paths
- Problematic tabbing sequences
- Crucial information being conveyed simply by site position or colour.
The Digital Accessibility Centre were excellent at catching lots of issues we missed, even ones we were specifically looking out for. They have a wide variety of agents covering a wide variety of accessibility needs. For example, users with differing degrees of blindness, who are not used to our site and must use screen readers. It sounds straightforward, but their strategy is effective at spotting (our) errors.
Some issues were obvious once pointed out, and had simply been overlooked, such as inverting the site colours leading to invisible logos, which is not at all good for branding or confidence in the site. This was found by a DAC agent with extremely limited vision, who had enlarged the page massively.
The FT.com teams are quite fluid, with lots of movement between teams, and teams coming and going. This resulted in a loss of rhythm in checking that new projects were accessibility-compliant.
The non-pausable video pre-rolls and GIFs were simply site initiatives which began after the last audit, and had slipped through the net without the accessibility implications being realised.
How did we tackle the Accessibility Anti-Patterns?
Two issues in particular triggered some interesting debate.
- A new design on an FT.com sub-site displayed text over images. This raises problems with contrast and readability, as well as causing problems for screen readers. The two main solutions for this situation are to increase the contrast of the text on the image or, as the FT has opted for and are rolling out, removing the text from the images. A designer was heard to say, “We are trying to communicate, not just make something that looks pretty”.
- On a page showing a video, we typically have two different links on the page which trigger the playing of the video. A screen reader tabbing across the page will come across a repeated call to play. By marking one of these two links, as “area hidden” we resolve that problem but DAC pointed out that we then had a play button which screen readers cannot interact with. After a discussion, a compromise was found, and DAC stated that this was acceptable, since it is consistent across the site as part of the o-video component.
There has been a revival of the accessibility initiative and mindset across the teams; a new generation introduced to it.
In the FT’s open source documentation site, there are examples of high contrast colours in the o-color Tinting set. As well as new tools being introduced in Origami (such this contrast ratio checker page), the UXD team have embraced desktop tools and plugins such as Stark, a color-blind simulator and contrast checker:
and Sim Daltonism, also a colour blindness simulator:
In total, over 20 separate issues arising from the audit were discussed, designed, fixed (in the short term), and checks put in place (for the long term), all in a short three day burst.
Accessibility is a journey, not a destination.
As a goal for an actively-developed website, with new features continually coming online, accessibility is never fully achieved (although the accreditation is nice!), but improvement is always worth striving for. We have found it leads to better motivated teams, fighting the good fight. It is a great lens through which to view all new design and developer initiatives. And of course, we end up with a site that is usable, or at least more-easily usable, by more people, and they can hopefully enjoy content from the FT.
This post was a collaborative effort from:
- Patricia Ofuono — Designer
- Mehmet Duran — Developer
- Chris Gathercole — Writer
- Georgina Murray — Editor