BBC Olympics: An accessibility case study

BBC Olympics
An accessibility case study
Alistair Duggin
London Web Standards - September 2013
Tuesday, 17 September 13

BBC Olympics Introduction
Alistair Duggin,
Lead Front End Developer,
BBC Sport Olympics Desktop Website
> About the Project
> Challenges
> Desktop and Tablet
> Lessons Learnt

About the Project

BBC Olympics About the Project
The first truly digital Olympics.
Never miss a moment
The most ambitious and comprehensive BBC digital project to date
Live and catch-up video at the heart of the BBC’s online coverage
24 high definition live streams
2500 hours of video coverage
Delivered to mobile, tablet, PC, and Connected TV
The first truly digital Olympics where the public would be able to never miss a moment

“Our aspiration was that just as the Coronation did for TV in
1953, the Olympics would do for digital in 2012
Phil Fearnley, General Manager, News & Knowledge at BBC

Built around the sports domain
Athlete
Usain Bolt
Event
Men’s 100m
Sport
Athletics
Venue
Olympic Stadium
Country
Jamaica
Interconnected nodes
Athlete - e.g Usain Bolt
Country - e.g Jamaica
Sport - e.g Athletics
Event - e.g Men’s 100m
Venue - Olympic Stadium

> 10, 000 Athlete
> 205 Countries
> 36 Sports
> 304 Medal Winning Events
> 30Venues
A page per domain item
... all interconnected

Page composed of components, including:
Facts and Figures
News
Video
Medals
Schedule
Results

Lots of other components
Make the experience as rich, engaging and interactive as possible.
Top trump style comparison components for countries athletes
Twitter modules
Components to promote live video streams
Carousel of to promote athletes and results

Each page type had an index page.
Countries.

Athletes - and the ability to ﬁlter by sport, event

Venues

Sports

An event index for each
sport

2 versions of a fully comprehensive schedule - a grid and a list view - providing alternative ways to get to the schedule information
that you wanted.
The schedule grid view provided an easily scannable visual interface

The schedule list view provided a more accessible text interface

The schedule allowed users to dig in and browse by sport

or by day

We also had Interactive medal tables.
That allowed users to browser medals by country

medal by
sport

And medals by
athlete

These pages were dynamically updated in real time
using data from the Olympics Broadcasting Service.

Other features included the interactive video player to watch live and on-demand video

A results section, providing by a 3rd Party, that contained details of every heat of every event.

And of course the sport news sections with content created by journalists.
This was an existing part of the website that we just added branding to.

Article
pages

Video
clips

Image
galleries

Live event commentary

Lots of this was also available on mobile

And all video and medals were available on connected TV
24 high deﬁnition live streams
2500 hours of video coverage

Tens of thousands of pages ...
possibly hundreds....

Usage and Stats
> 37 million UK browsers
> 66% UK online adult population
> 57m global browses
> 111m video requests across all platforms
We knew the website was going to be popular - but I don’t think anyone imagined it would be quite the success it was.

Challenges

BBC Olympics Challenges
Developer challenges ...
Accessible to all
> Size of project
> Immovable deadline
> 17 day event
> Huge audience
> High Proﬁle
> Real-time data
> Up front design
> Lots of javascript
> Multiple teams
> Mixed knowledge of accessibility on teams
Huge amount of effort going into to making it available on many platforms.
On the desktop we wanted to make sure it was accessible to all - irrespective of people’s device or ability. First project I’ve worked
on where this was made a clear priority right from the very top.
Australian olympics website had been sued in 2004 for being inaccessible.
Easier said than done.

BBC Olympics Challenges
What is accessibility?
A range of capabilities
> Visual
> Auditory
> Motor
> Cognitive
Characteristics of accessibility
> Perceivable
> Operable
> Understandable
> Robust
Web accessibility refers to the inclusive practice of making websites usable by people of all abilities and disabilities - irrespective of
the device they are using

Desktop and Tablet

BBC Olympics Desktop and Tablet
The Development approach
> Build with accessibility in mind - from the start
> Speak to specialists early
> Training - screen readers,WAI-ARIA
> Set up a support network and share best practices
> Front-end developers create UI before integration
> Brainstorm multiple solutions and seek feedback
> Agile
> Test thoroughly
> Component library
> Web Standards and Progressive Enhancement
Screen reader training with AbilityNet
Aria, javascript and HTML5 training with The Paciello Group - based around upcoming components
Support forum for a month - to answer questions
Work with milestones: test early, test often

One of the ﬁrst things we did when was analyse the designs looking for common styles and patterns that could be abstracted out
into reusable code.
This helps you build things faster.
Also helps a consistency of implementation which is better for users

The other thing we did was build each component in such a way that it could be dropped into any page.
Much quicker to build a site from reusable components. Having a library also promotes reuse and consistency of implementation.
This started as just a static library (HTML and CSS) - but evolved into components that used mock data. This meant we could get
components to load different variation of expected data so we could conﬁrm that they worked for all expected scenarios.
This helped hugely with testing. Could point testers to a page and get them to conﬁrm that they worked as expected. Also meant
that we could ask Henny to test things as soon as they were built - rather than having to wait for the components to appear on web
pages that were being driven by test data.

> HTML5 doctype
> Lang attribute
> Skips links
> Unique title
> Unique h1
> WAI-ARIA landmark roles
Page Templates

Web standards and
Progressive Enhancement
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript
WAI-ARIA for Javascript
Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web
page

> Add content in logical order
> Alt text for images that need it
> Captions for tables
> Full text for abbreviations
Content
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript

> Use most appropriate elements
> Add hierarchical heading structure
> Add content images
> Don’t duplicate links
> Links make sense out of context
> Code tables correctly
> Code forms correctly
> ARIA roles & attributes where useful
> Validate
Core functionality available through links and forms
HTML
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript
Semantically structured
HTML

> Implement non-js layout
> Take care with display:none
> Focus aswell as hover - no outline:0
> Font size +2
> Don’t use !important
> Check Font size +2
> Check for colour contrast
> Check with images off
> Check visual state is also in content
layer
CSS
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript
Take care to not implement barriers with CSS

> Feature detection
> Valid JS generated HTML
> Update state labels - open/close
> Hijax - http before ajax
> Update screenreader virtual buffer
> Check keyboard access to all
content
> Check no keyboard traps
JavaScript
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript

> Contextual CSS body=”js”
> Prevent ﬂicker as js loads
CSS for Javascript
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript

> Keep users informed (live regions)
> Manage focus (tabindex 0 and -1)
> Implement keyboard controls
> Use appropriate WAI-ARIA
attributes - roles, states and
properties
> Provide hidden instructions
Content
HTML & WAI-ARIA
CSS
JavaScript & HTML
CSS for Javascript
Keep users informed - loading, new content
Treat aria as an enhancement - not widespread support or familiarity by users

Sometimes not possible to have a non-js version
- schedule module
- favourites tray
That’s ﬁne - you need to be pragmatic!
Follow as similar approach though - content in logical order, semantic and valid markup, avoid css gotchas, manage keyboard focus
etc

Interactive Medal Tables
* Built to work without javascript.
* deliver something quickly.
* real pages that you can bookmark and email
* if there is an error it will still work
* Logical Content order - go to any page without javascript and the content is in logical order.
* Most appropriate markup - <th> for countries, caption and summary
* Identify which content is selected in content layer as well as visual layer.
* Alt for medal images
* Visible active state for keyboard users
* Keyboard short cuts
* Inform users that content is loading
* Users taken to loaded content
* Use Browser API so back button still works

Issues we ﬁxed...

Fixed: Colour contrast
Problem - Design/CSS
Failed colour contrast test
Fix:
Changed colours

Fixed: Over complicated markup
PROBLEM: HTML
Aural clutter - headings inside lists
FIX:
Refactor HTML

Fixed: Broken navigation when resized
Problem - Design/CSS
Failed colour contrast test
Fix:
Changed colours

Fixed: Favourite Button
Problem: HTML generated by JS
span used instead of div - can’t receive keyboard focus
Fix:
Feedback issue - got them to use a button

Fixed: Keyboard inaccessible video clips
Problem: JS generating span instead of link
Unable to play video with keyboard as span used instead of button
Fix:
Added in a link to control video

Fixed: Keyboard trap
Problem: JS
Inﬁnite scroll resulted in keyboard trap

Issues that got released...

Compromise: Colour only medals
Problem: medal communicated by colour only
If colour blind won’t know what medal
Why not ﬁxed:
Design didn’t want to change

Compromise: Country page content order
Problem: Design/logical content order
Design meant not in logical order
Fix:
Designers didn’t want to change design

Compromise: Indistinguishable Links
Problem: Design/CSS
Can’t see links until you roll over them
Why not ﬁxed:
Changed by another team due to request from design. Ran out of time to chase up.

Compromise: Info graphics
<img src=”rivals.jpg”
alt=”Bolt graphic” />
Problem: adequate alternate text not provided
Lots of information in graphic - editorial didn’t include adequate descriptive alt text

Compromise: Auto Suggest not read out
Problem: Javascript
Suggested athletes not read out
Why not ﬁxed:
Not part of stable release of jquery ui. Ran out of time.

Compromise: Auto refresh
Problem: JS
Can’t turn off auto-refresh
Completely unusable by screen reader user
Use of non-semantic markup
Why not ﬁxed:
Built by an3rd Party. Fed back issues but they didn’t have time/inclination to ﬁx

Lessons Learnt

BBC Olympics Access services
Lessons Learnt
> Team effort - every role has a responsibility
> Easy to introduce issues at all levels
> Collaborate
> Seek help from specialists
> Progressive Enhancement is good
> Test early and often
> 100% accessible not realistic - need to prioritise
> Accessibility does not have to compromise design
You don’t need to compromise design for accessibility

Alistair Duggin
http://alistairduggin.co.uk/
@dugboticus

BBC Olympics: An accessibility case study

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to BBC Olympics: An accessibility case study

Similar to BBC Olympics: An accessibility case study (20)

Recently uploaded

Recently uploaded (20)

BBC Olympics: An accessibility case study

Editor's Notes