Accessibility on the BBC Olympics Website

Presenters

 

INTRODUCTION

  • About the project
  • Accessibility at the BBC
  • Challenges
  • Desktop and tablet
  • Video
  • Mobile
  • Lessons learned

 

First truly digital Olympics, a very ambitious project

  • Aspiration was that it would have same impact as Coronation did for TV in 1953
  • Built around sports domain, a page per domain item; all were interconnected
  • Showed slide with content chunk breakdown
  • Lots of other components as well (comparison of performances, Twitter, promo, medalists, etc.)
  • Index page for everything (countries, sports, events, athletes)
  • All dynamically updated in real time using data from the Olympics Broadcasting Service
  • Most of it on mobile and even TVs
  • Usage and stats:  37 million UK browsers (66% of UK online adult population, and other very large numbers

 

ACCESSIBILITY AT THE BBC

  • Long history of accessibility
  • BBC Trust and charter
  • Lead by example (both internal and external)
  • License fee (we’re a public service, we answer to the public)

 

CHALLENGES

Accessibility consultant challenges

  • Size (web, mobile, video)
  • Standards and guidelines
  • Training
  • Ownership and responsibility (2 people were working full-time on accessibility at the BBC at the time)

Developer challenges

  • Size
  • Immovable deadline
  • 17 day event
  • Huge audience
  • High profile
  • Real-time data
  • Up front design
  • Lots of javascript
  • Multiple teams

 

DESKTOP AND TABLET

  • Accessible from the start
  • Speak to specialists early
  • Training – screen readers, WAI-ARIA
  • Research best practices
  • Set up a support network (made sure our work was peer-reviewed)
  • Front-end devs create the UI before integration
  • Brainstorm multiple solutions / Prototype / Iterate
  • Feedback issues early
  • Agile build and test (2 week sprints with prioritized backlogs)
  • Component library

PAGE TEMPLATES

  • HTML5 doctype
  • Lang attribute
  • Skip links
  • Unique title
  • Unique H1
  • WAI-ARIA landmark roles

 

Open Standards and Progressive Enhancement Made this all possible

  1. Content
  2. HTML and WAI-ARIA (hierarchical heading structure, used HTML5 elements with care, don’t duplicate links, code tables and forms correctly, etc.)
  3. CSS (take care with display:none, Focus as well as hover, font size +2, don’t use !important, etc.)
  4. JavaScript and HTML (feature detection, valid JS generated HTML, update state labels, no keyboard traps)
  5. CSS for JavaScript (contextual CSS body=”js”)
  6. WAI-ARIA for JavaScript (keep users informed, manage focus, implement keyboard controls, etc.)

 

ISSUES WE FIXED

  • Color contrast
  • Over-complicated markup (even if semantically correct, could be cluttered when uttered)
  • Broken navigation when resized
  • Favorite button
  • Keyboard inaccessible video clips
  • Unexpected keyboard controls
  • Keyboard trap (in a twitter module with infinite scroll)

 

ISSUES THAT GOT RELEASED

  • Color only medals
  • Country page content order
  • Indistinguishable links
  • Info graphics
  • Auto suggest not read out (jQuery live regions didn’t work at the time)
  • Auto refresh (built by external vendor)

 

VIDEO

Interactive Media Player

  • BBC Sole rights holder
  • 24 live streams
  • Flash player (being able to switch channels while within the player was key)
  • Fully immersive “lean back” experience

Approach

  • Tender and contract
  • BBC Standards and Guidelines
  • Requirements and User Acceptance Criteria
  • In house testing
  • User testing with disabled users
  • Document for player UI:  IVP Interface – Tabbing and Screen Reader Support v2

Requirements

  • No autoplay
  • No background image interference
  • No flashing
  • Contrast
  • Text size

Choice was important for IVP (Interactive Video Player)

  • Alternative was provided that used HTML controls
  • What do we call it?  Accessible, Alternative, or something else?
  • 3 links above HTML version (Default player, Alternative player, Pop-out player)
  • “Choose how you watch” text was an H2
  • Accessible tooltips provided
  • Help link beneath players
  • Separate play / pause buttons, or single switch button?
  • HTML controls didn’t work in full screen mode

Access Services

  • Live “enriched commentary fo the Opening Ceremony
  • Audio only on TV
  • Audio and video via the web
  • Subtitles for BBC One, Two and Three
  • No controls over the other streams

Compromises

  • IVP not as accessible as planned
  • Immovable deadline
  • Decided not to promote it as accessible

We offered

  • Mobile web site
  • Apps for Android 2.2+ and iOS5+ (Offline storage, Personalization)
  • Shortcut on Blackberry
  • Live and catch up video

The Challenge

  • Expertise and experience
  • Standards and guidelines
  • Testing and evaluation

BBC Mobile Accessibility Guidelines

  • Technology agnostic standards and guidelines
  • HTML, iOS and Android techniques
  • Evaluation criteria

Approach

  • Use standard not custom components
  • Progressive enhancement
  • Follow platform specific guidelines

Structure

  • H1 – H6
  • Landmarks
  • Data tables

Alternative

  • HTML:alt
  • Android:contentDescription
  • iOS:  UIAccessibilityLabel / Trait / Hint

Changes of state

  • Tab panel
  • Open / close

Announce Changes

  • Update the alternative
  • Visible changes

Compromises

  • Pinch / zoom
  • Assets – arrows
  • 3rd party content (didn’t know how compliant it’d be)

Lessons Learned

  • Documentation
  • Sign off at UX
  • A variety of testing
  • Progressive enhancement is key
  • Easy to introduce issues at all levels
  • 100% accessible is not realistic – need to prioritize

 

QUESTIONS

  • Have the accessibility processes learned here been sustained and ongoing?  Yes, it has raised awareness in a really big way, especially with mobile.
  • What tool for evaluation?  Some automated testing was done, but no enterprise tools in-house