BBC Olympics: An accessibility case study

BBC OlympicsAn 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 dateLive and catch-up video at the heart of the BBC’s online coverage24 high definition live streams2500 hours of video coverageDelivered to mobile, tablet, PC, and Connected TVThe 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 2012Phil Fearnley, General Manager, News & Knowledge at BBC



Built around the sports domain

AthleteUsain Bolt

EventMen’s 100m

SportAthletics

VenueOlympic Stadium

CountryJamaica


Interconnected nodesAthlete - e.g Usain BoltCountry - e.g JamaicaSport - e.g AthleticsEvent - e.g Men’s 100mVenue - Olympic Stadium


> 10, 000 Athlete> 205 Countries> 36 Sports> 304 Medal Winning Events> 30 Venues

A page per domain item

... all interconnected



Page composed of components, including:Facts and FiguresNewsVideo MedalsScheduleResults


Lots of other components


Make the experience as rich, engaging and interactive as possible.

Top trump style comparison components for countries athletesTwitter modulesComponents to promote live video streamsCarousel of to promote athletes and results


Each page type had an index page.Countries.


Athletes - and the ability to filter 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 definition live streams2500 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 Profile> 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 AbilityNetAria, javascript and HTML5 training with The Paciello Group - based around upcoming componentsSupport forum for a month - to answer questions

Work with milestones: test early, test often


One of the first 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 confirm that they worked for all expected scenarios.

This helped hugely with testing. Could point testers to a page and get them to confirm 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 flicker 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 fine - 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 fixed...



Fixed: Colour contrast


Problem - Design/CSSFailed colour contrast test

Fix:Changed colours


Fixed: Over complicated markup


PROBLEM: HTMLAural clutter - headings inside lists

FIX:Refactor HTML


Fixed: Broken navigation when resized


Problem - Design/CSSFailed colour contrast test

Fix:Changed colours


Fixed: Favourite Button


Problem: HTML generated by JSspan 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 linkUnable to play video with keyboard as span used instead of button

Fix:Added in a link to control video


Fixed: Keyboard trap


Problem: JSInfinite scroll resulted in keyboard trap


Issues that got released...



Compromise: Colour only medals


Problem: medal communicated by colour onlyIf colour blind won’t know what medal

Why not fixed:Design didn’t want to change


Compromise: Country page content order


Problem: Design/logical content orderDesign meant not in logical order

Fix:Designers didn’t want to change design


Compromise: Indistinguishable Links


Problem: Design/CSSCan’t see links until you roll over them

Why not fixed: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 providedLots of information in graphic - editorial didn’t include adequate descriptive alt text


Compromise: Auto Suggest not read out


Problem: JavascriptSuggested athletes not read out

Why not fixed:Not part of stable release of jquery ui. Ran out of time.


Compromise: Auto refresh


Problem: JSCan’t turn off auto-refreshCompletely unusable by screen reader userUse of non-semantic markup

Why not fixed:Built by an3rd Party. Fed back issues but they didn’t have time/inclination to fix

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 Dugginhttp://alistairduggin.co.uk/@dugboticus



Technology

BBC Olympics: An accessibility case study