Ensuring iPlayer is accessible to all
The iPlayer website is built so that all users can enjoy BBC content, regardless of what access technology they might use, how they access the content, or what disabilities they may have. We have built accessibility in from the outset, following the BBC Accessibility Standards and Guidelines, and have of course taken into account user feedback.
From time to time, there may be some areas in which we can improve the user experience. While some areas can be addressed fully by ourselves, others are dependent on browsers or access technology software.
In addition to manual testing on various devices using technologies such as NVDA and VoiceOver (many other screen-readers are available), as well as user testing, we also use a few automated tools to check the iPlayer website for common areas that accessibility-related functionality can be improved. These tools are Google’s Lighthouse, an open-source tool called aXe, and a BBC-built tool, bbc-a11y. Of course, there’s plenty of testing tools out there, but these are the three we’re trying out at the moment. I’ll talk through what these are and how we use them, as well as a little about some features developed specifically for people with certain needs, but first, a little on how we build accessibility in from the ground up.
Building accessibility in from the start
Here at iPlayer, we like our users to have a consistent experience across the website, so to make it easier for us to develop new features quickly and more easily, we’re developing a Component Library. This package houses all our components, including buttons, links, icons, responsive images, banners and episode items. As we create these components, we’re taking time to ensure accessibility-related features come built-in to them, such as aria-labels, alt attributes, visible focus styles, focus order and colour contrasts.
For example, if a developer uses the responsive image component without specifying any alt text, the component will default the alt attribute to empty, rather than not having an alt attribute. This is because most screen-readers will read out the filename of an image when no alt attribute is specified, whereas if the alt attribute is blank, they will normally ignore the image, which is generally what we would want if we don’t have alt text for it.
Another good example is our page tear component — the close button label is a required property, meaning the developer must specify what should be read out when a screen-reader user navigates to it — after all, navigating to a button and the screen-reader simply reading out “button” is no use to anyone!
A third great example is our Content Item component (currently used for promoting programmes on the homepage) — this component encapsulates all the information in one single link (to prevent duplicate links), and with an aria label to improve how the information is read out.
Building the site in this way means we can spend more time thinking about how to make each component as good as it can be, so that once it’s built, we can drop it in anywhere on the site without having to fully re-consider all the various requirements again.
Lighthouse
Currently we run this tool from time to time, using the audits pane in Google Chrome. This will occasionally pick up on mistakes that we’ve made or on areas we can improve. We’re proud to say that the iPlayer homepage currently gets a score of 100 out of 100!
We are also currently in the process of setting up a NodeJS build job on our CI (Continuous Integration) server that runs the accessibility audit (using the Lighthouse npm package) on Chrome Headless (using the Chrome Launcher npm package with the relevant flags), so that we can more easily detect areas for improvement during the build pipeline and monitor existing issues over time.
aXe
Since there’s no one tool to rule all tools, we also run the aXe Chrome extension. Developed by Deque, this tool also runs in the browser and aims to highlight potential accessibility-related issues. Unlike Lighthouse though, in addition to its concrete tests, aXe also flags up aspects of the page that need human intervention to test. For example, aXe flags up that elements on the page with a background image may not pass colour contrast checks, but it can’t be sure since a background image isn’t a solid colour.
Just like Lighthouse, aXe currently gives us full-marks for the iPlayer homepage, reporting no accessibility violations! It does suggest we manually review the colour contrast of the items on the page though, due to the fact that we have a background image.
bbc-a11y
In addition to Lighthouse and aXe, we’ve also recently started using an internally-built tool, bbc-a11y. This tool runs a number of tests against a given set of URLs to verify whether or not each one meets the BBC accessibility standards. It works by opening the given URLs using Electron and running some Javascript on the page to run the assertions.
We’ve added this tool to our CI server and in to the pipeline for the majority of the website (which is built on micro-services), which means that if we introduce any potential issues that bbc-a11y picks up, our pipeline will be ‘unstable’ and we can halt the deploy before it gets to the live environment, meaning we can change our code before the users get the update.
Accessibility features
Developing a truly accessible website isn’t just about perfecting the markup and ensuring screen-reader users can use it — it’s also about ensuring that all users have an easy journey to find and access the content they need.
Whilst we have had audio-described and signed versions of our programmes available for years now, it’s not been a particularly quick journey to access these versions, even if the user has already watched some of it — users would have to find the default version of the episode, then find the relevant button to switch version. We’ve recently made iPlayer more intelligent and personalised in this area — it now remembers what version of a programme you were watching, so when you return to iPlayer to resume watching that episode or to watch the next episode, the link in the “Continue watching” section will now take you straight to the right version.
We’ve got some ideas for more similar features, so keep an eye out!
