Accessibility on the BBC Olympics Website

Presenters

• All Duggin – @dugboticus – http://alistairduggin.co.uk/
• Henny Swan – @iheni – http://iheni.com

 

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