Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Accessibility Originates With UX: A BBC iPlayer Case Study

Not long after I started working at the BBC, I fielded a complaint from a screen reader user who was having trouble finding a favorite show via the BBC iPlayer’s home page1. The website had recently undergone an independent accessibility audit which indicated that, other than the odd minor issue here and there, it was reasonably accessible.

I called the customer to establish what exactly the problem was, and together we navigated the home page using a screen reader. It was at that point I realized that, while all of the traditional ingredients of an accessible page were in place — headings, WAI ARIA Landmarks2, text alternatives and so on — it wasn’t very usable for a screen reader user.

The old iPlayer homepage3
iPlayer’s old home page. (View large version4)

The first issue was that the subnavigation was made up of only two links: “TV” and “Radio,” with links to other key areas such as “Categories,” “Channels” and “A to Z” buried further down the content order of the page, making them harder for the user to find.

The old iPlayer homepage with Categories, Channels and A to Z highlighted5
iPlayer’s old home page showing “Categories,” “Channels” and “A to Z” far down the content order. (View large version6)

The second issue was how verbose the page was to the screen reader user. Instead of hearing a link to a program once, the program would be announced twice because the thumbnail image and the heading for the program were presented as two separate links. This made the page longer to listen to and was confusing because links to the same destination were worded differently.

Duplicated links highlighted on the old iPlayer homepage7
iPlayer’s old home page showing duplicate links. (View large version8)

Finally, keyboard access on the page was illogical. In the “Categories” area, for example, a single click on a category would reveal four items in a panel next to it. To access the full list of items in that category, you had to click again on the same link to be taken to a listing page. This was a major hurdle for the user and the place where the customer I was talking to gave up using the application altogether.

Categories, highlighted on the old iPlayer homepage9
iPlayer’s old home page showing the “Categories” links highlighted. (View large version10)

It was clear that, while the website had been built with accessibility in mind, it hadn’t been designed with accessibility in mind and this is where the issues originated.

The Challenge Link

At the BBC, a number of internal standards and guidelines are in place that teams are required to follow when delivering accessible website and mobile applications. Key ones are:

There is also a strong culture of accessibility; the BBC is a publicly funded organization14, and accessibility is considered central to its remit and is a stronger driver than any legal requirement. So, how did this happen?

Part of the issue is that standards and guidelines tend to focus more on code than design, more on output than outcome, more on compliance than experience. As such, technically compliant pages could be built that are not the most usable for disabled users.

It may not seem immediately obvious, but visual design can have a massive impact on users who cannot see the page. I often find that mobile applications and websites that are problematic to make accessible are the ones where the visual design, by dictating structure, does not allow it.

This does not mean that standards and guidelines are redundant — far from it. But what we have found at the BBC is that standards need to sit within, and inform, an accessibility framework that runs through product management, user experience, development and quality assurance. As such, accessibility originates with UX. Most of the thinking and requirements should be considered up front so that poor accessibility isn’t designed in.

While redesigning the BBC iPlayer website, renewed focus was given to inclusive design, which, while adhering to the BBC’s standards and guidelines, is driven by four principles (more on that below). We then distilled our standards and guidelines to create a focused list of requirements for the UX to follow. We also started to train designers to annotate their own designs for accessibility.

UX Principles Link

Our four main principles are the following:

  • Give users choice.
  • Put users in control.
  • Design with familiarity in mind.
  • Prioritize features that add value.

Give Users Choice Link

Never assume that just because a user can access content one way that they want to access content in that one way. Because BBC’s iPlayer has “audio described” and “sign language” formats, it was never in any doubt that both of these should have their own dedicated listing pages, accessed via the “Categories” dropdown link. (Note that all on-demand content is subtitled, which is why there is no “Subtitled” category. Subtitles can be switched on in the media player.)

The Categories dowpdown with Audio Described and Signed sections15
The “Categories” dropdown with “Audio Described” and “Signed” sections. (View large version16)

User research and feedback indicated, however, that although people want dedicated categories, they also want to be able to search for and browse content in the same way that any other users would and to select their preferred format from there. I have stayed in touch over the years with the gentleman who complained about the old iPlayer page, and he’s said himself, “Don’t send us into disability silos!”

This means that from the outset the designs need to signpost “Audio Description” and “Signed” content via search results, A to Z, category and other listing pages. Not making any assumptions or not stereotyping users with disabilities is important — for instance, a person with a severe vision impairment might not always use audio descriptions; news, sports, music programs and live events often aren’t supported by audio description because commentators already provide enriched commentary.

Alternative formats shown in listing pages17
List pages such as search, shown here, indicate what formats programs are available in. (View large version18)

On-demand pages also list alternative formats, allowing users to choose what they want. Looking ahead, the option to choose your format could also be included in the Standard Media Player19 — the BBC media player used for on-demand and live streaming video across all BBC products, including iPlayer.

Playback pages showing high definition and audio described formats20
Screenshot of the playback page showing HD and AD formats. (View large version21)

Put Users in Control Link

Never taking control away from the user is essential. A key aspect of this in iPlayer, which is responsive, is not suppressing pinch zoom. Time and again in user testing, we have observed users zooming content, even on responsive websites, where text might be intentionally larger.

Due to an iOS bug that was rectified in iOS 6, the ability to pinch zoom was suppressed on many websites due to poor resizing when the orientation is changed from portrait to landscape. Now that this has been fixed, there is no reason to continue suppressing zoom.

Another aspect of control is autoplay. While iPlayer currently has autoplay for live content, this can be a problem because the sound of the video can make it difficult for a screen reader user to hear their reader’s output. However, we do know of screen reader users who request autoplay because it means they don’t have to navigate to the player, find the play button and activate play. The answer is to look at ways to give users control over playback by opting in or out of autoplay, such as by using a popup and saving preferences with cookies.

Design With Familiarity in Mind Link

There needs to be a balance between the new and the familiar. Users understand how to interact with pages and apps that use familiar design patterns. This is especially important in native apps for iOS and Android, where standard UI components come with accessibility built in.

Equally important is the language used across the BBC’s native iPlayer apps and responsive website. Where the platform allows, consistent labels for headings, links and buttons — not just visually, but also via alternatives for screen reader users — ensure that the experience is familiar and recognizably “BBC iPlayer,” regardless of the platform.

Tied into this, the new designs reinforce a logical heading structure within the code, which in turn supports navigation for screen reader users. Key to this is ensuring that the pattern used for the heading structure is repeated across pages, so that users do not find main headings in different places depending on what page they are on. While structure is typically viewed as a responsibility of developers, it needs to be decided before designs are signed off in order to prevent poor structure getting coded in — more on that later.

Prioritize Features That Add Value Link

Accessibility at the BBC is not just about meeting code, content and design requirements, but also about incorporating helpful features that add value for all users, including disabled users. A large proportion of feedback we get from our disabled users pertains to usability issues that could be experienced by anyone on some level but that seriously adversely affect disabled users. When we incorporate features to help users with specific disabilities, everyone gains access to a richer and easier experience.

One obstacle that comes up time and again is finding a favorite show. I’ve spoken with many screen reader users who say they save shortcuts to their favorite shows on their desktop but, due to changing URLs, often lose content. A simple way to address this that benefits all users is to ensure that there is a mechanism for saving favorites on the website. Adding in options to sort favorites and list them the way you want further improves this. It may sound unrelated to accessibility, but it was the single most requested feature received from disabled users. Simply accessing the favorites page to watch the latest episode of something, rather than having to search the website, makes all the difference.

Sorting favourites using A to Z and recent options22
The “Favourites” page, with options to sort by “A to Z” and “Recent”. (View large version23)

Finding ways to allow people to get to the content they want more quickly has also influenced what is available within the media player itself. Once an episode has finished playing, exiting the media player and navigating back to the website to find the next episode is a massive overhead for some users. Adding a “More” button to the player itself — showing the next episode or programs similar to the current one — cuts down on the amount of effort it takes users to find new content.

The Standard Media Player plug in for related content24
The “You may also like” plugin shows related content and next episodes within the Standard Media Player. (View large version25)

One key feature that has added value to BBC iPlayer’s native iOS and Android apps, as well as the website (when viewed in Chrome), is support for Google Chromecast26. Being able to control what content you view on TV without having to use a remote or complex TV user interface is invaluable. Using one’s device of choice, whether it be iOS or Android, is much easier for a disabled user than using a remote control and a potentially inaccessible TV interface.

Chromcast on BBC iPlayer27
BBC iPlayer and Chromecast. (View large version28)

Guidelines Link

The principles above exist to create a mindset that helps product owners and UX practitioners alike when shaping and designing inclusive products. In addition to the four principles, a set of guidelines is used to design more accessible interfaces. The following are a subset taken from the “BBC Mobile Accessibility Standards and Guidelines29”:

  1. Color contrast
    Ensure that text and backgrounds exceed the WCAG Double A 4.5:1 contrast minimum.
  2. Color and meaning
    Information conveyed with color must also be identifiable from context or markup.
  3. Content order
    Content order must be logical.
  4. Structure
    When supported by the platform, pages must provide a logical and hierarchical heading structure.
  5. Containers and landmarks
    When supported by the platform, page containers or landmarks should be used to describe page structure.
  6. Duplicate links
    Controls, objects and grouped interface elements must be represented as a single component.
  7. Touch target size
    Targets must be large enough to touch accurately (44 pixels).
  8. Spacing
    An inactive space must surround all active elements (unless they are large blocks exceeding 44 pixels).
  9. Zoom
    Where zoom is supported by the platform, it must not be suppressed.
  10. Actionable elements
    Links and other actionable elements must be clearly distinguishable.

The New iPlayer Link

Keeping in mind this backdrop of principles and guidelines, along with the renewed focus on adding value and features that enhance the experience for disabled users, here are a few of the changes introduced in the BBC’s new iPlayer:

The new BBC iPlayer homepage30
The BBC’s new iPlayer home page has better content order, search tools, structure and keyboard access. (View large version31)

At launch, the iPlayer’s navigation housed the BBC’s channels, a “TV Guide,” “Favourites” and “Categories.” These all sit at the start of the page, high up in the content order. While they are visually easy to see, they are also easily discoverable by screen reader users via a hidden heading and labeled navigation landmark:

<div role="navigation">
<h2>iPlayer navigation</h2>

Where previously the “Categories” were unusable for the screen reader user I spoke with, they are now prominent in the page and fully keyboard navigable. Since launch, the addition of more channels has meant that the channel links have been rehoused in their own dropdown menu.

Search tools have also been added, enabling users to carry out predictive search, browse A to Z or view their most recently watched program. This is all keyboard accessible, it makes use of headings, and it has landmarks where appropriate.

The home page carousel is also fully keyboard accessible. Each program in the stream is presented as one link, with the reading order of text starting with the primary information first: channel attribution, program name, episode information, abstract and program duration.

Work has also been carried out to improve visible focus and bring both the iPlayer website and the Standard Media Player in line with the BBC header and footer. The pink underline used for the hover and focus states in the main BBC navigation is now used within the Standard Media Player to indicate when a button is selected — for example, when the subtitles are switched on. This replaces the use of color only to indicate a selected state, which was indistinguishable from the hover and focus states.

BBC navigation hover and focus states32
The hover and focus pink underline used in the BBC header for iPlayer. (View large version33)
Hover and focus states used for the subtitle button on the Standard Media Player34
Active and inactive hover and focus states on the subtitle button in the Standard Media Player. (View large version35)

You can read more about what steps were taken to make iPlayer web-accessible36 and to make the Standard Media Player accessible37, including creation of an accessible media player in Flash38, on the BBC’s Internet Blog.

Annotated UX Link

All of the thinking around inclusive design that comes from product owners, UX practitioners and designers needs to be captured and communicated to developers and engineers. At the BBC, we are moving to a model where designs need to be annotated for accessibility. This includes:

  • headings,
  • containers,
  • content order,
  • color contrast,
  • alternatives to color and meaning,
  • visible focus,
  • keyboard and input interactions.
Annotated UX for the iPlayer homepage showing headings, lists, labels and content order39
An example of an annotated UX showing headings and labels. (View large version40)

The design above, showing an early version of the BBC One home page in iPlayer, outlines where the <h1> to <h6> headings should be. The UX practitioner doesn’t need an in-depth knowledge of code, but rather an understanding of the hierarchy of data within a page. As such, an equally acceptable approach would be to indicate the “main heading,” “secondary heading,” “third-level heading” and so on. Developers can then take this and translate it into semantic markup.

Equally, indicating the logical order of content helps developers to code content in the right sequence (i.e. source order) — something that is essential to a screen reader or sighted keyboard user’s comprehension of the page.

Annotating the UX in this way is key to identifying designs that don’t allow for a logical page structure, content order or behavior. It is the first step to generating a style guide that documents focus states, colors and so on. Further down the line, these requirements can also be used to generate user acceptance criteria and automated quality assurance tests.

Even if you’re working in an agile way, where designs are iterative and not delivered in a complete form, annotation still works. As long as the basic framework of the page is well defined, the visual design can evolve from that.

Summary Link

It’s very easy to get bogged down by accessible output and to forget that, ultimately, accessibility is about people. As such, keep the following in mind, whether you are working in product, UX, development or quality assurance:

  • Design with choice in mind.
  • Always give users control over the page.
  • Prioritize features that add value for disabled users.
  • Design with familiarity in mind.
  • Integrate accessibility into annotated UX and style guides.
  • Make no assumptions. Test ideas and concepts.

Fostering these key principles across the entire team will go a long way to ensuring that products are inclusive and usable for disabled people. Listening to users and actively including their feedback, along with adhering to organizational standards and guidelines, are essential.

(hp, il, al, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


In her capacity as User Experience and Design Lead at the Paciello Group (TPG) Henny Swan looks at ways of integrating the principles of inclusive design early on in projects. She joined TPG in 2014 having previously worked at BBC, Opera Software and Royal National Institute of Blind People. Henny has a particular focus on mobile and multimedia bringing her experience to bear on products delivered on multiple platforms. Previous work has included BBC iPlayer (web, iOS and Android), BBC Olympics, BBC Sport and the BBC cross platform Standard Media Player.  

  1. 1

    Fascinating insights and a good overall article Henny!

    I remember speaking to you about accessibility for the Olympics 2012 project(s)…it’s great to see since then that you’ve managed to introduce some of the good standards work into other areas accessed by millions, and on such a great product too. Keep it up!

    • 2

      Thanks Dan. Wow, 2012 seems like a distant memory but it certainly was a turning point for how we approached inclusive design at the Beeb. I’ve since left but I know the team are really making progress at supporting UX and devs alike to create accessible content.

    • 3

      Personally I have supplied feedback ranging from major bugs to minor ux annoyances but none of these appear to have any level of importance.

      For example:
      1. Lack of sound when restarting a programme on a Samsung TV. It is necessary to restart from the beginning and fast forward.
      2. It is unclear that the top nav bar is highlighted so I frequently press right only to switch to a new category which has a very slow load time and then need to slow switch back…
      3. Most popular used to be a category and is now an annoying vertical list which I find far less useful.
      4. Why is radio it’s own app, and why keep a link to it that requires multiple clicks to open?
      5. Why is the interface to the radio items so much worse than it was previously? Specifically the radio dial style interface is a horrible idea, and the drop down menu categories is much worse than it used to be. There is no need for it to be dramatically different to the TV interface.

      • 4

        Hi Tez – all valid points. Familiarity is key, as the article says, however design needs to work within the constrains of the platform and their design patterns which also hold value and familiarity for users.

        I’m not as familiar with the iPlayer TV apps as I am web/mobile however I am aware that a lot of user research was done before separating TV and radio for mobile apps. I’ve since left the BBC but if you contact accessibility at bbc dot co dot uk your feedback will be fielded there.

  2. 5

    I am confused, why would a person who needs a screen reader will be using a touch screen device? How does he navigates it?

    Other than that – great article! Some of the insights here are relevant for SEO too as bots are not very different in their way of accessing a page.

    • 6

      Hey Martin – touchscreens are a primary way for screen reader users to access content these days. Mobile platforms come bundled with a mobile screen reader (VoiceOver on iOS and Talkback on Android) that, when activated, reads out everything on screen.
      You can navigate by swiping up, down, left or right to set focus on previous or next content – much in the same way as a desktop user might use the TAB and ARROW keys. Equally you can use explore-by-touch and move your finger across the screen to listen to what is directly under your finger. This works for web content and native apps as long as they have been build with accessibility in mind.
      You can read a bit more about it on ‘Mobile And Accessibility: Why You Should Care And What You Can Do About It’ ( . Heydon Pickering also has a book out called ‘Apps For All: Coding Accessible Web Applications’ which is a good read ( I also have resources on my blog at
      And you are spot on about SEO, there is an overlap with accessibility.

  3. 7

    @iheni Minor typo: contrast should be 4.5:1 for WCAG2 Level AA :P

  4. 9

    Great article!

  5. 10

    Exactly! UX and conformance are not the same! Very impressed with some of the UX designs. A much better experience. Was wondering about the need for aria-hidden in some places such as:

    What’s the purpose of using aria-hidden here? I did some testing and didn’t notice a need. However, I don’t have much AT at my disposal. Thanks!

    • 11

      <div class="play-icon">
      <i class="icon tviplayericon tviplayericon-iplayer" aria-hidden="true"></i>

      • 12

        Hi Vincent – if you are referring to the sub navigation this was changed after my time so I wasn’t involved with the discussions. In checking with the team however it seems that on smaller screen sizes the element contains the down arrow icon for the Categories sub-menu as an icon font and CSS content. Without aria-hidden some screen readers read the content (e.g. VoiceOver on OSX). A combination of using a pseudo-element and aria-hidden means that it is always ignored. There is more info on this at

  6. 13

    Sheetal Kondhare

    February 26, 2015 11:46 am

    Hey Henny,

    Very nice & detailed article. Loved it. Thank you for the pointers that need to be considered at wire-framing stage.


  7. 14

    I need to better understand the colour ratios, any chance of a follow up article? When I explore this with Colour Contrast Analyser the bright pink used extensively on iPlayer fails except at large sizes making it an unreliable colour – despite it looking great! I find bright colours often fail – especially if inverted or greyscaled which some screen technologies will allow users to do.

    • 15

      With contrast there’s actually a couple of things going on. The WCAG talks about the “contrast ratio”. There’s actually 3: luminosity contrast– the numbers in the WCAG use this. It’s determined by this algorithm:
      (relative luminance of light colours + 0.05) / (relative luminance of dark colours + 0.05))
      –but there are also brightness differences and colour differences.
      Brightness is determined by
      ((Red value x 299) + (Green value x 587) + (Blue value x 114)) / 1000
      Colour difference by
      (maximum (Red value 1, Red value 2) – minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) – minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) – minimum (Blue value 1, Blue value 2))

      These were in WCAG1, but it seems luminosity alone is in WCAG2.
      Most of the time, when I change contrasts in ZoomText, things with passing luminosity (4.5.1) are still contrasty enough in the other contrasts, but not always. Greyscale can also sometimes fade things that pass, but these contrast changers are often switched on or off as needed by people as they go through websites. Lots of people probably have trouble with the black iPlayer even with sufficient contrast, while other people read better if *most* sites were light text on black.

    • 16

      …and yeah I’m measuring 3.8 here, and lots of that text wouldn’t count as “large”.

    • 17

      It’s ironic to be reading about contrast on this Smashing Magazine page, where the contrast is frequently very poor, e.g. left nav and links in the text.

  8. 18

    Great writeup, I did prefer the old layout though as it did the job. It’s great to redesign, but current users are used to setup and these changes can be seen as annoying. Onto my main point, I’m in Asia. I can use the iPlayer for radio but for tv I get an error message. I know you want to make iPlayer accessible, but if most of the modern world cannot even see the content then you’re really catering to a small audience.

    • 19

      Hi Giles, change is always tricky and it can be hard for people to transition to new layouts. I do believe that in this case it was for the better as the site is much more accessible.

      Due to TV licensing iPlayer TV is only available to UK residents which is why you get the error message. You can read more about it here:

  9. 20

    Wonderful article, thank you. Those principles are great.

    When you wrote: “It was clear that, while the website had been built with accessibility in mind, it hadn’t been designed with accessibility in mind” did you mean useability the second time?

    • 21

      I meant accessibility. If semantics, content order, keyboard interaction, colour etc are not considered when designing the site (before it is coded) you make the product more vulnerable to being less usable for disabled users as poor design gets hard coded.

  10. 22

    Put users in control. Love it!

  11. 23

    Great read, Henny.

  12. 24

    There is so much information about accessibility. But why buttons are replaced with links (). Buttons must be marked up as buttons.
    Another issue – there is no label for search input. Placeholder is not enough. Every form field must be labelled.


↑ Back to top