Technology + Creativity at the BBC Feed

New look subtitles and playback for BBC iPlayer on TV

2021-04-08T08:00:32+00:00

From today, we’re rolling out a new look for BBC iPlayer’s playback on TVs. It’s a cleaner, sleeker and more pared-back interface, with some changes to how things appear during playback and new, improved subtitles you can customise and control.

The first thing most viewers will notice is the playback bar along the bottom. You will now see a simple, elegant bar that shows how far through the programme you are.

Gone is the play/pause button - play and pause icons are now briefly displayed in the centre of the screen when pausing and resuming, whilst rewinding and fast-forwarding brings up visual stills from the programme, so you can easily see when to press play again.

All the extra controls for more episodes, subtitles and settings and the button to add a programme to your list to watch later have all been moved to the top left of the screen.

As part of these changes, we’ve also made significant improvements to the way viewers can control subtitles on iPlayer. The new position of the subtitles and settings menu makes it easier than ever to turn subtitles on or off, as well as making it easier to choose the audio described and signed versions where available; plus, we’ve also added the ability to change and control the size of the subtitles.

Previously subtitles on iPlayer were automatically displayed as a larger size than we use on broadcast, so as part of these changes, we’ve made the default setting a smaller size. For those who need larger or, indeed, even smaller text, they can now choose from a range of five options. That choice is remembered for other programmes they watch in the future.

These changes follow some other recent improvements we’ve made to subtitles on iPlayer on TV. Previously subtitles would appear as coloured sans serif text with a black outline, always at the bottom-middle of the screen. This was far from ideal as, for example, it could be difficult to read the white text if the video image behind it was also white or was patterned. And if the part of the video image behind the subtitles contained something that viewers needed to see to understand the programme – for example, the clues on Only Connect – they could only see it by switching subtitles off.

The improvements we’ve made recently mean when you’re watching iPlayer on a TV, subtitles are now clearly readable, in the BBC Reith Sans typeface, with a black background behind the text, and the correct colours to show who is talking. They are also now positioned to take account of what’s on-screen, so they will no longer be covering important information, and mean our viewers who use subtitles can play along with Only Connect and enjoy Victoria Coren-Mitchell’s witty and withering jokes at the same time.

Currently, the new size controls are only available on our on-demand content but will be coming to live channels on iPlayer in the coming weeks. Let us know your feedback on the new look playback interface, the new subtitle controls or anything else at bbc.co.uk/contact.

> BBC iPlayer - Accessibility

> BBC Technology + Creativity - Accessibility

> BBC R&D - Casualty - Accessible and enhanced audio trial

An accessible digital BBC – 2019 in review

2020-01-15T10:19:46+00:00

BBC for Everyone – take 1 clapperboard

The BBC Accessibility Champion Network is probably one of the oldest in the industry. This year it surpassed 200 champions. There is also an alumnus of 75+ now encouraging inclusive design and accessibility elsewhere in the industry. Here are the top highlights of many accessibility improvements in BBC digital products this year:

UX&D and Internal Tools:

The ‘BBC for Everyone’ video was published by GEL, along with draft technical docs. Neurodiversity won awards. Internal S&SD did screen reader user research for Optimo, a new article editor for News journalists. They also reviewed and improved accessibility of Audiences, the new site for audience research, reports and data.

iPlayer and Sounds:

The web media player introduced subtitle size controls. iPlayer added an ‘Accessibility Help’ link for assistive technology users. iPlayer and Sounds both made efforts to respect an individual’s 'reduce motion’ choice, which can be set in their OS preferences. iPlayer Mobile adopted an ‘accessible first’ mantra to work on a new player interface, available to opt in and try via the app settings. Work has included research with screen reader users and raising issues with OS providers. Behind the scenes work was completed that enabled both iPlayer TV and the new mobile player to add in-player controls for audio description and sign language. iPlayer and Sounds both have active accessibility guilds, and have integrated accessibility into processes, engineering methods, and testing strategies.

iPlayer Accessibility Help link

Children’s Games & Apps:

Research relationships continued with Seashell Trust and Everyone Can. It enabled and supported user research for CBeebies, CBBC and Bitesize games and interactive content, in turn guiding work on relevant content and the ‘Accessible Games Guidelines’. Bitesize Primary
improved keyboard accessibility across their existing practice games. They also launched 7 new games, with 8 more in development, that deliver on at least one accessibility ‘pillar’.

News:

News index pages became more consistent, easier to navigate, and introduced the BBC Reith font, which is clearer and easier to read on small screens. World Service sites are being re-built with accessibility embedded at every stage. This has extended the champion network outside the UK. Accessibility swarms checked new components built for elections. And Visual Journalism considered accessibility from the start of each project. A scrolling story format that is keyboard accessible and has a toggle for animation is one example of the outcomes from that. The integrated approach shows how Catharine Green becoming Accessibility Lead was a decision that established accessibility as a clear priority for News.

Sport:

Following the example of News, Sophie Beaumont became Accessibility Lead for Sport, and an Accessibility Guild was set up. They embedded accessibility considerations into all team processes and built up a prioritised backlog of improvements. The teams have since created new pages and features that are some of the most accessible Sport experiences yet.

Weather:

A redesign of tide table pages for Coast and Sea section means they are now responsive, more legible and ‘glanceable’, and adapted for touch devices. The improved navigation for future dates also links to an accessible table version of the information with live updates provided to assistive technology. And animated indicators update in real time while adhering to an individual’s ‘reduce motion’ preferences.

Web Core:

This year a big change of direction toward a centralised approach took shape. The goal is a shared, non-versioned kit of parts, from which to create digital products and services. The team are building brand new components following the GEL technical docs. The docs provide pragmatic advice for actual implementation with accessibility built in. This approach should also mean that future accessibility improvements roll out fast.

Voice & AI:

New tech on the block means a lot of user research. This has ensured the BBC’s collective Alexa skill is intuitive to navigate while reducing distraction and cognitive load. And it’s informing work begun on ‘Beeb’, a voice assistant from the BBC. Accessibility is a key requirement of both the user interface and brand development.

BBC Studios:

The commercial arm of the BBC may need a slightly different approach, but accessibility is still a key requirement. A redesign of Top Gear has provided the perfect opportunity to educate the team and make accessibility part of the end-to-end process of delivery.

Elsewhere:

Small changes, like improving link text in the cookie banner or checking the accessibility of a new local search feature before implementation, can ensure a better experience for many people. Though our champions don’t keep to small. Many blogged and presented this year, including Peter Gould and Nicola Quinn. They presented “How to Bake Muffins” at a #BuildTheBBC event open to the public. A heart-warming tale about why accessibility should be considered from the start of a project. Peter also built taba11y in his spare time, a useful Chrome plugin already being used in-house.

taba11y enumerating tab stops

Coming Up

Most BBC teams now ‘bake in’ accessibility. Look out for improved universal sign-in and children’s sign-in from BBC Account team. And also improved audience participation experiences. Research is being conducted to support insights into how children with varied and complex impairment use technology. Other research is looking at how to make interactive content more accessible for neurodiverse users. And the new accessibility guilds and groups in Bitesize, iPlayer& Sounds, and Voice & AI should make an impact throughout 2020.

Conversations have definitely moved on from explaining ‘why’ accessibility is important. We now talk collectively about ‘how’ we deliver accessibility. A champion network that keeps accessibility part of the daily conversations is pivotal to that shift. The BBC sets an accessibility benchmark that many organisations strive to emulate. No easy feat in the constantly changing and evolving digital space. An active network of Accessibility advocates, our Champions, Leads, Groups and Guilds, is what makes that possible.

Mixing Audio Description for BBC iPlayer

2019-08-20T13:09:02+00:00

In 2009, iPlayer became the first video on-demand service to offer Audio Described content. Audio description makes video content more accessible to blind and visually impaired people by explaining what is happening on screen. This helps viewers with visual impairments to follow what is going on.

This external content is available at its source: iPlayer AD guide

Back then, iPlayer was a catch up service for the BBC: programmes would only be available on-demand for a limited period after they had been broadcast and recorded from terrestrial TV streams. Since then, iPlayer has evolved, allowing programmes to be made available before they are broadcast. This is made possible through our file-based delivery workflow which has been in place since 2013 and enables pre-recorded shows to become available on iPlayer as soon as or before they are broadcast on TV.

Unfortunately, as of 2018, audio described content was still living in the catch-up paradigm, where content was only made available on iPlayer after it had been broadcast. This meant that old shows, Doctor Who for example, made available again as box-sets on iPlayer, but not scheduled for the TV, did not have their audio described version made available.

This was a frustration for our viewers who could regularly access audio described content on iPlayer, but would find some programmes missing their audio described version even if it had been available in the past, or was to be broadcast in the near future.

With Killing Eve season 2 released on iPlayer as a box-set with all episodes available with an audio described version, I felt it was a good time to tell our side of the story. This blog post will cover some of the tech we used to make audio described content available on iPlayer.

The media files

To create audio described programmes we need two types of media.

Video file of a scheduled programme (MXF file)

We receive a video MXF file, from the production team who made the programme, in a very high quality, high-bitrate AS-11 DPP format. This is a format developed in conjunction with other UK broadcasters for file-based delivery workflows. The MXF file contains the video and the original programme audio without audio description and is used to create all the different formats needed to stream or download our content. It may be in stereo or surround sound, standard definition or HD. You will see that the audio described version of the programme is also created in the AS-11 DPP format with the same quality and features as the regular programme but with audio description dubbed in.

Audio Description Studio Signal (AD WAV file)

An audio description studio signal is produced and delivered to us by our partner Red Bee Media in a stereo WAV format. The left channel contains the audio described voice track, with no original programme audio and the right channel is control data, not something you’d want to listen to unless you find a fax machine weirdly soothing. The control channel is used to dip the original programme audio so as to ensure the audio description is audible over any background audio in the programme. This paper from BBC R&D has more detail on the audio description studio signal.

The media tools

To do the mixing we use the following tools.

Gstreamer

Gstreamer is an open source multimedia framework that we use with an audio description plugin developed by David Holroyd. The plugin only works on audio so the original programme audio must be extracted. It mixes the original programme audio and the audio described voice track, adjusting the gain of the original programme audio as signalled by the control track so that the audio description can be clearly heard. The output is a single mono track so this has to be run twice, once on the left audio channel and once on the right audio channel, for a stereo programme.

Principles of fading original programme audio during description passages. Source: WHP051

BMX

BMX is an open-source project from BBC R&D to read and write MXF file formats in common use at the BBC, written by Philip de Nier. It has had many uses in the BBC over the years, most recently as a widely-used engine for generating DPP files. We use the following utilities from BMX to create our audio described content:

bmxtranswrap to extract the stereo audio channels from the MXF file and convert them to uncompressed WAV format.
mxf2raw to extract the MXF metadata and raw essences, which are the video and audio elements.
raw2bmx to assemble an MXF from the metadata and raw essences

The process

The following steps outline how we use the media files and tools to create an audio described version of a programme. These are the instructions implemented in our code that we deploy on EC2 instances in AWS.

Preparing the AD WAV file

We receive AD files in a mixture of 16 and 24 bits, so we normalise them all with Gstreamer to 16 bit. We now have:

Extracting the audio from the MXF file

First, we extract the left and right audio channels from the MXF and convert them into separate mono WAV formatted files.

Each audio channel starts with what is called a “handle” — a term for a sequence of tones used for broadcast timing. The video also includes a ticking clock during this handle period. We need to remove the handle from the audio before we can mix, as the AD file does not contain the handle stage.

So we extract the handle and store it for later. Finally, we extract the audio after the handle to give us just the original programme audio. The audio is now ready to be mixed.

Mixing the audio description with the original programme audio

The Gstreamer plugin then mixes the original programme’s left and right audio channels with the audio described track. The handle is then prepended to both channels so that they are now in sync with the video. This creates our final mixed audio described tracks ready for reassembling.

Extracting essences

We need to extract all the essences from the original MXF file to then insert the mixed audio described tracks. The essences will consist of the AS-11 metadata, one video essence — the main bulk of the MXF — and the audio essences. The essences look like:

Metadata: as11-core.txt, as11-dpp.txt and as11-segments.txt
Video: essence_v0.raw
Audio: essence_a0.raw essence_a1.raw

Assembling the final MXF file

The mixed audio described tracks are used in place of the audio essences, but all other original extracted essences, video and metadata are used to construct the new audio described MXF. We now have our audio described MXF that is used in our file-based delivery workflow to create the compressed assets that can be played in iPlayer.

The quirks

Performance

Downloading, uploading, extracting and assembling media files is a slow process. This is due to the size of an MXF file. An hour-long HD MXF file will be around 60GB. Processing a file of that size takes considerable time. We took some steps to reduce the processing time by using an i3.large instance for its high network performance and high I/O performance with SSD storage.

With these features, an instance can still take over 40 minutes to complete one mix. This raises a problem for auto-scaling instances.

Auto Scaling

It is common for our components to scale out when work piles up in the form of messages on our instance’s input queue, similarly scaling in when work is low. We want to prevent scaling in from terminating an instance that is currently processing one of the messages and doing work.

Instance protection allows an instance to protect itself from a scale in event by requesting protection from the AutoScalingGroup API. When one of our components will have a long running process like creating audio described content it will protect itself when it starts processing a message, then removing that protection after the message and work has been completed.

Long-term storage means long-term costs

To reduce storage costs for the BBC, once a programme’s availability has expired on iPlayer, only the original MXF file is kept for long-term storage. All other versions of that programme are removed, including the audio described version. This is why in the past audio described content that was previously broadcast did not reappear on iPlayer when its original version was made available again.

This is no longer a problem, because the audio description studio signal is now kept in long-term storage. An audio described version of a programme is now recreated when ever the programme is rescheduled for the iPlayer. This is more cost effective than storing the audio described version.

Testing with Docker

The majority of our micro-services don’t manipulate media; that is done with on-site hardware or third party cloud transcoders. The audio description workflow is different. It relies on the tools mentioned above: tools that only a few of our developers have installed locally. We could have mocked the calls and just checked the functionality of the code, but we wanted something a bit more robust.

With Docker we are able to run our code and tools as if they’re running on an EC2 instance, thereby testing the whole audio description workflow locally and in our continuous integration workflow. We do this with a base image of our underlying EC2 instance’s OS and installing our project as an RPM. When testing, we overwrite the compiled jar on the image with a local copy to avoid rebuilding the image.

Interested in learning more?

Creating an accessible media player in Flash

2014-07-07T06:54:20+00:00

Hi, I’m a Senior Software Engineer with the BBC Media Playout team. We are responsible for producing and maintaining the Standard Media Player (SMP).

Standard Media Player

The Standard Media Player is built on two core technologies, Adobe Flash and HTML5, and uses a decision engine to embed the appropriate client based on platform and device - for example the SMP Flash player is served to desktop and laptop computers, whilst the SMP HTML player is embedded on iOS devices. For desktop, Flash currently remains the primary method of delivering media playback to our users and this presents us with several challenges when making our services accessible to the widest range of users.

Accessibility and Flash

With the rise of HTML5 most browsers and operating systems provide good integration for accessibility (screen reader support, tab controls etc) however Flash has always been problematic and requires a lot more custom code in order to meet basic accessibility requirements. The launch of SMP allowed us to completely rebuild our accessibility implementation and ensure the player was designed and coded with the BBC Accessibility Guidelines in mind.

The nature of Flash has always presented a challenge for users of assistive technologies. There are a number of technological and design considerations that must be taken into account when building accessible Flash content:

- A Flash movie consists of dynamic, vector-based graphics most of which are not identifiable to screen reader technologies in the same way a static HTML tag is

- Components are not always laid out in a logical or obvious fashion when compared to HTML

- Content in a Flash movie usually updates or animates, a visually impaired user may not be aware of this change

- Browser support for Flash varies massively between player and OS versions

- Screen reader and other assistive technologies have varying levels of support for Flash, in some cases none

- Flash is a browser-based plugin; OS accessibility settings such as colour contrasts will not be applied to Flash content

- Flash security restrictions prevent accessible keys working in full screen mode

For this post I’m going to talk about how we addressed two fundamental accessibility requirements when building the Standard Media Player for Flash, keyboard controls and screen reader support.

Keyboard Controls

BBC accessibility guidelines, in keeping with existing W3C guidelines, state that all BBC websites and services must be fully controllable using the keyboard alone,

This covers a few basic concepts:

1. a user must be able to tab forwards and backwards into an interactive component

2. the component must have a clear focused state to indicate where the user is focused

3. the component must have a shortcut key where logical

4. if the component is a button then it must be activated with either the space or enter key

TabIndex vs Custom implementation

Flash already has basic tabbing functionality built in to allow display objects to be accessed via the keyboard. By setting the tabEnabled and tabIndex properties against a DisplayObject instance you are inserting it into the tab order of the movie and letting Flash player do the work when it comes to tab key events and moving focus between objects.

Click here for a GitHub snippet on basic tab controls on a Flash Sprite

This approach to keyboard controls works well with a Flash movie embedded in page (with the stage.displayState property set to normal) and is the option many developers end up using as it requires very little custom code to implement. The problem with using the default tabbing functionality comes when we enter full screen. Flash security restrictions for full screen mode block most keyboard interactions including enter, space and other shortcut keys, which renders most buttons and interactive components useless. This obviously causes problems for keyboard users wanting to operate video in full screen mode.

To address the tabbing problems in SMP we decided that manually controlling the tab index in code was preferable. It not only allowed users to control playback in full screen mode but also helped prevent keyboard traps.

Code Example – Manually Control Keyboard Tabbing

Avoiding Keyboard Traps

A common problem encountered on any web page using Flash is tabbing from the HTML elements of the page to the plugin itself. The Flash player plugin is independent of the tab ordering of the page in which it is embedded, and so the user runs the risk of becoming keyboard trapped inside the Flash movie. This problem is nicely summarised by the W3C.

“The problem is that, while both the Flash content and the HTML content around it may be keyboard accessible, many browsers do not support moving keyboard focus between the Flash content and HTML content without using a mouse. Once focus is placed inside the Flash content, a keyboard user will be trapped there. Similarly, when focus is placed somewhere else on the HTML content (outside the Flash content), it will be impossible to move focus into the content.”

The workaround for this issue is to provide two anchor points either side of the Flash movie that Flash is aware of and can manually pass focus to and from.

Tab ordering between HTML and Flash

Tab ordering between HTML and Flash

This can be achieved relatively easy using a combination of JQuery and Flash ExternalInterface calls.

Code Example – Using an External Interface for Key Focus.

The reverse can also be achieved when tabbing backwards from a HTML element to the Flash movie.

Code Example – Handling Keyboard Traps in HTML.

Screen Reader and Assistive Technology Support

Screen readers are technologies that “scrape” a user interface or web page and attempt to convert display elements into another output medium, the most obvious ones being braille and text-to-speech. For HTML based web pages this is a relatively simple task, a screen reader can identify each component based on its HTML tag, an input field, a combo box etc, and can interpret what to do with it. With Flash based components a screen reader is normally unable to interpret the function of a display object and users can become lost when navigating within the movie.

When coding components for screen readers a few basic rules must be followed:

1. any interactive object must have an audio tooltip or alternative text, usually the name of the control

2. the control must be descriptive enough to describe its function, is it a button, slider etc

3. the control must have a description on how to operate it, e.g. press ‘Enter or Space to activate’

4. the screen reader must be notified when a component updates or appears, e.g a buffering spinner appears or a component is focused

Microsoft Active Accessibility (MSAA)

Assistive technology adds capabilities that the computer doesn't usually have. For example, a visually impaired user might employ assistive technology such as a screen reader and voice recognition, rather than directly using the application with the mouse and screen. The Microsoft Active Accessibility API was first introduced to Windows as a means of allowing assistive technologies access to control and read applications as well as non-standard UI components. It provides a method for identifying and manipulating user interface controls through non-standard means and allows the same components to alert the system when they change state, e.g. being focused or clicked. Later versions of Flash Player added support for the MSAA spec.

Interactions between the user and the assistive technology interface

The MSAA API allows user controls or visual components to be assigned specific roles; these help the accessibility API to determine what the control does, its current state and how any assistive technologies can best interact with it. For example, a user control that can be clicked can assign itself the role of ROLE_SYSTEM_PUSHBUTTON to inform any accessibility tools that when this component is focused it can be clicked on. More complicated roles include ROLE_SYSTEM_SLIDER which identifies the component as a slider that can be controlled by incrementing and decrementing values.

For a list of the most common MSAA roles see Mozilla’s list.

Whilst this Flash implementation is based on the MSAA spec there are newer accessibility APIs including IAccessible2 which is used in Firefox and Open Office and Microsoft UI Automation, the successor to MSAA.

Adding Alternative Text to Flash Components

The first step in making a Flash component accessible is to tag it with the necessary name and description, when the component becomes focused it will inform the screen reader of its descriptive name and how to operate it.

Flash provides this functionality as part of the AccessibilityProperties class.

Code Example – Setting Accessibility Properties on a Flash Sprite

Initialising the Accessibility API

Interacting with the screen reader is done via the Accessibility class.

When a web page is loaded, a screen reader will take a snapshot of the page and maintain it in a virtual buffer, this needs to be kept in sync when the page changes. For static HTML a screen reader can simply traverse the DOM but in Flash we must manually call back to the screen reader to inform it when the movie updates. This call need only be sent once to prevent spamming the screen reader with alerts, normally after all UI components have been initialised.

Code Example – Updating a Screen Reader from Flash.

Accessibility Implementations

As mentioned above, Flash conforms to the MSAA spec which allows display objects to be tagged with specific roles, in Flash this can be done by the AccessibilityImplementation class.

By tagging a component with an accessibility implementation a screen reader can query it to determine its function, its current state and its default action when activated.

Interaction between a screen reader and an MSAA component

The AccessibleButtonImplementation.as in the project link below is an example accessibility implementation for a push button, it defines how the component operates when focused, its default action and the command to run when that action is triggered by the screen reader.

Code Example – Accessibility Implementations for a Push Button and Slider.

The button implementation is a very basic example of what can be achieved but shows that you can cater the functionality of a Flash component to better suit the needs of an accessible user if required. You should avoid overcomplicating an interface, avoid nesting accessible components or controls with too many operations, sticking to simple buttons and form elements makes for a better experience and quicker navigation via the keyboard.

For more example accessibility implementations see the Adobe Open Source repo.

Sending Screen Reader Alerts

Occasionally you may wish to inform a screen reader that an operation has taken place without prior user interaction, in the case of a media player this could mean a buffering spinner or error message has been displayed. To avoid confusing the user as to why playback has been interrupted we want to send an audible alert to the screen reader. This can be easily achieved by taking advantage of screen reader support for HTML, by adding a Flash ExternalInterface callback to the webpage we can dynamically create hidden HTML alerts which are detected and read aloud by the screen reader.

Code Example – Using an External Interface to send screen reader alerts

Example Code

A working example of all of the concepts discussed can be found on GitHub, or try out our full accessibility implementation using a screen reader on the BBC iPlayer website.

Supported Audio Screen Readers

Based on our research and testing we have determined that the best supported screen readers for Flash Player are Jaws and NVDA . However there are many other products available including Microsoft Narrator, Nokia Talks, WindowEyes, ZoomText and Supernova, all have varying levels of support for Flash and should be considered when testing.

Due to Flash Player’s implementation of MSAA at the time of writing we only fully support Flash accessibility on Windows devices using Internet Explorer or Firefox. Support for Macintosh users with VoiceOver enabled is unfortunately not available as VoiceOver support for Flash was never implemented and Adobe recently announced their intention to scrap development of an accessible Flash Player for Macintosh. Screen reader support for Flash Player in the Google Chrome browser is also problematic as it bundles its own custom PepperFlash plugin which is incompatible with current screen reader implementations.

The Future

Developing accessible services is a constant, iterative process of user testing and playing catch-up with browser and Flash Player updates. As browser based technologies move on, new standards and alternatives to Flash become more widespread the Standard Media Player will continue to evolve to support them. The mobile and touch screen space also continues to expand - with the launch of services such as Chromecast we are able to investigate alternative user experiences that go beyond sitting in front of PC which may better suit accessible users.

You can read more about our efforts to bring accessibility to SMP and BBC iPlayer in Henny Swan’s post here.

Due to the specialist requirements that go with building accessible services we do encourage users of assistive technologies and those with other requirements to get in touch to help us develop services further - we’d love to hear your thoughts in the comments below or via the Accessibility email.

Dan Oades is a Senior Software Engineer, Media Playout Team, BBC Future Media

Standard Media Player: accessibility

2014-07-04T13:05:56+00:00

The Standard Media Player (SMP) is at the centre of BBC online delivering audio and video content across all BBC products such as News, Sport, Weather, iPlayer, Radio and live events. It is a responsive player that replaces a variety of legacy players with a goal of delivering great quality playback, consistency and a better user experience across products and devices.

The SMP also acts as a platform on which new features, in the form of plugins, can be added to help users search, discover and save their favourite content as well as customise their audio video experience. You can read more about it in Cathy Bartlett’s blog post.

Masterchef in the SMP showing a plug in for adding programmes to favourites

Making the SMP both accessible and usable for disabled users is core to the player’s success. At the BBC we don’t just aim to comply with our standards and guidelines for accessibility but also consider the needs of disabled users when prioritizing features. We aim to add features that we know add value, improve user experience and ease of use for disabled users and not just able-bodied users. A good example of this was adding Chromecast to iPlayer earlier this year.

Other barriers of access can fall outside of traditional standards and guidelines. By removing legacy players we removed a very significant barrier: inconstancy - not just in terms of what features were offered within players but also levels of accessibility. More effort can now be put into a single unified, accessible player, which in turn frees up resource so we are not just maintaining accessibility but also building on what is already there.

For this initial release of the SMP we focused on three core areas of accessibility: better visual design, better presentation of subtitles and improved support for assistive technologies such as screen readers and voice input software.

Better visual design

Previously buttons would have hover states for mouse users but default to the Flash yellow outline for keyboard only users. Whilst technically accessible this didn't make the player feel very inclusive for sighted non-mouse users. We've now replicated hover states on focus and added visible tooltips, where necessary. In doing this we also reviewed our selected/active states so that if, for example, subtitles are switched on colour alone is not used to indicate selected states but also an underlines. This helps users visually understand what is on and off within the player.

Subtitle active and inactive hover and focus states

One subtle benefit of this is that the SMP inherits the colour of the BBC product it is being viewed in so, for example, on iPlayer pink is used. Using the pink for the underline to indicate ‘on’ helps not just reinforce meaning but also brand.

Better subtitles

One very important aspect of the visual design is the size, colour and positioning of subtitles. A new feature of SMP is the ability to find related content from within the player via a 'More programmes' panel or plugin. The positioning of the 'More programmes’ panel however is on the lower half of the screen just above the player controls where subtitles are traditionally positioned. This is obviously less than ideal as by obscuring subtitles users have no way of knowing if there is dialogue when simultaneously viewing content and exploring what's coming up next.

We commissioned some research with 24 subtitle users in order to understand where users wanted subtitles to be positioned on desktop and tablet (there is no ‘More’ panel on mobile).

Users placed paper cut outs of subtitles where they would like to see them on desktop

As a result of the findings the subtitles now get pushed above the player controls when the controls are open and to the top of the page when the 'More programmes' panel (visible in iPlayer in full screen) is open.

Subtitles positioned at the top of the screen in full screen

We have also implemented different colours for different speakers and plan to do further work around size and positioning based on some of the feedback we have already received.

Support for assistive technologies

We've worked hard to improve screen reader and voice input support where we can. This has included better keyboard accessibility as well as clear alternatives for buttons so screen readers and voice input users can navigate the SMP on desktop, tablet and mobile.

We ensure changes of state - such as Play/Pause, Turn Subtitles on/Turn subtitles off - are communicated audibly just as they are in the visual design via a tooltip and a colour change and underline. We've also followed standard keyboard conventions and communicated this via audible tips for screen reader users so they can get the most out of the player.

The HTML player, which is available on iOS tablets, has been brought in line with the Flash player so that the player sounds and 'feels' the same to the screen reader user as it does on desktop.

While Flash is a great technology we are restricted in the number of screen readers we can support as some screen readers, such as OSX VoiceOver, don't handle Flash at all while others, such as Jaws and NVDA might behave differently to one another. Screen reader behavior can be further complicated by whether they are working in Internet Explorer, Firefox, or when working in page or in full screen. We provide a link from the player to the SMP accessibility FAQ which contains guidance, tips and details about supported software, how to access and possible issues.

The Media player help link becomes visible when focused

We now have Audio Described programmes working on mobile and tablet browsers. This is the first time AD content has been available on iPlayer via anything other than computer. Additional work is also being carried out on on adding AD in to our TV and mobile apps.

You can read more about adding support for screen readers in Dan Oades forthcoming blog post creating an accessible media player in Flash. Here I’d like to touch upon a couple of usability aspects of ensuring the SMP is usable for blind users.

Now that the initial release of the SMP is live we are looking ahead to what we can do to build on it as an accessible audio and video platform. Key areas are:

• continuing to improve subtitle, sign language and audio description delivery across all platforms and devices that can support it including live subtitling,

• continuing improvements for screen reader and for voice input users,

• creation of tools and features to enable fast and efficient discovery of content.

Finally we are considering making the SMP open source. For the BBC, open source software development is an extension of our Public Service remit. By making the Standard Media Player open source audiences would get additional value from work they’ve funded as well as speed up the pace of innovation in a more accessible player that would benefit users beyond the BBC. In a small way we already get invaluable feedback from our disabled users who contact us with questions, comments and feedback. We always review this feedback to make technical improvements and help us assess features that might add value so open sourcing SMP would fit very well with this model.

As the Standard Media player evolves so will the accessibility. Hearing feedback from you and other users is invaluable and really helps us better understand how to make the player more usable so if you have any comments or questions please post them below or email us.

Henny Swan is Senior Accessibility Specialist, BBC Future Media

Accessibility on BBC iPlayer on Chromecast

2014-04-07T06:35:11+00:00

Hi,

Two weeks ago Google Chromecast launched in the UK with BBC iPlayer on Android and iOS adding support on the same day. On Friday of last week we added Chromecast support to the new version of BBC iPlayer on desktop and laptop computers using the Chrome web browser. For those that have not come across Chromecast before it offers an easy way to stream media to your TV by plugging a Wi-Fi enabled HDMI dongle into your TV set. When you cast from BBC iPlayer you can then stream audio and video to your TV from your device via apps that have the Chromecast feature enabled or from the Google Chrome browser when the Chromecast extension is enabled. Chris Yanda’s blog post explains more.

Chromecast on an iPad

Chromecast allows you to use your device as a remote control and cut out using TV remotes and user interfaces. This is a significant step in providing additional choice in how disabled audiences can consume BBC iPlayer content as for many disabled people using a remote control or navigating a TV interface can be problematic. Using an already familiar device such as Android or iOS that offer a multitude of accessibility settings that allow mobility, vision, hearing or cognitively impaired users to effortlessly cast content to their TV could be a significant step forward.

Obvious beneficiaries are blind and partially sighted users who would otherwise have to invest in TVs with talking menus, which can be costly, or rely on sighted assistance. A wide variety of other users may also benefit: older users, people with low vision or cognitive impairments who may find it hard to understand a TV interface or what button does what on a TV remote. If you use a smartphone or tablet it is arguably easier to learn how to use one device that you can use for multiple tasks rather than a variety of devices for a multiple tasks.

For blind and low vision users, as well as some users with cognitive impairments, both the BBC iPlayer iOS and Android apps have labels on all the Chromecast buttons that can be read out. Using Android Talkback and iOS VoiceOver you can expect to be able to connect Chromecast to your TV, play/pause content, rewind and forward-wind content and adjust the volume. Subtitle users can also switch subtitles on and off from their device and stream them directly to their TV.

Our approach to accessibility in BBC Future Media is to not just make products accessible but to also look at how new features can enhance access to our content. While we aim to follow BBC Accessibility and Mobile Accessibility Standards and Guidelines and embed accessibility from the outset during the design phase of a project, we also think about how proposed new features might positively impact disabled audiences. Chromecast is an obvious candidate as it affords many benefits to a wide variety of users.

This is a first pass. The potential for Chromecast, and other technology like it, is significant. We will be fine-tuning this implementation and seeing what else we can do with it and as such we’d be interested to hear your view. Either leave a comment below or email us at accessibilityteam@bbc.co.uk.

Henny Swan is a Senior Accessibility Specialist, BBC Future Media

Making the new iPlayer accessible for all

2014-03-13T10:41:32+00:00

Hi,

I work in the Accessibility team in BBC Future Media. We provide tools, training, and support to teams within the BBC so that they can deliver web content and applications that are accessible to disabled audiences.

Earlier this week a public preview of the new BBC iPlayer on the web was released. This new site replaces separate mobile, tablet and desktop sites with one responsive site. In streamlining the user experience for all users we wanted to also exceed existing levels of accessibility with the current BBC iPlayer and, more importantly, make the site more usable for disabled users. To do this we embedded accessibility into the design and development process from the outset. This post talks through some of the headlines of how we went about doing this.

The new BBC iPlayer replaces mobile, tablet and desktop sites with one responsive site

It was important for us to understand what we were trying to achieve from the start as well as understand how we were going to achieve it. We ran training courses for the user experience, developer and test teams to make sure that everyone understood what their role and responsibilities were and where to find resources such as the BBC Accessibility Guidelines and the newly published Mobile Accessibility Standards and Guidelines.

User Experience

Before we began work we already had a lot of data and user feedback about likes and dislikes with the existing iPlayer website. This was fed into the design process helping to shape wireframes and UX along with the BBC requirements of standards and guidelines.

One reoccurring piece of feedback was that it was impossible to tell from the search results page which programmes were audio described or subtitled. We addressed this by listing all programmes in the search results page together with the alternative formats they are available in such as AD (Audio Description), SL (Sign Language), HD (High Definition) and SD (Standard Definition). Just as before Audio Described and Signed also get their own Category while you can turn on Subtitles on all on-demand content using the subtitles button from within the player.

Search results listings now show Audio Described and Signed programmes

Design was not signed off until it was annotated for accessibility. The site was broken down into page templates and shared modules, the wireframes for which were then annotated to ensure what was being proposed could be made accessible, how, and to iron out any major issues prior to development. Typically annotated UX would include:

• Structure – annotations for headings, sub headings, lists and areas for WAI ARIA (Web Accessibility Initiative Accessible Rich Internet Applications) Landmarks

• Keyboard access – visible focus states for elements and unique selected states (e.g. for menu items), clarification of where to set focus when page content updates, content order and focus order

• Colour – meeting the 4.5:1 colour contrast minimum, use of colour to reinforce meaning (and not rely on it)

This proved invaluable. Even though the UX evolved as development got underway it meant we had a uniform, accessible framework from which to hang designs. It also allowed us to anticipate potential issues before they got coded. For example early on we decided that we wanted to list each programme as a list item rather than a heading. We felt pages would otherwise become overwhelmed with too many headings, which would undermine their value as a means to navigate for screen reader users.

The popup box has a visible tick to show it is selected

For the benefit of sighted non-mouse users care has been taken to ensure clear focus states are used as well as unique selected states. To avoid confusion for those that may not be able to differentiate colour some features, such as the Change Language and Change Location module, also include a visual prompt, a tick, to make it very clear what is selected and what is focused.

Another outcome of annotating UX was that we were able to build up BBC iPlayer specific requirements for accessibility, above and beyond the BBC standards and guidelines, which are particular to the needs of the site. For example, with regards to the main heading of pages, the H1, we decided it should always follow the ‘main’ Landmark in the content order. This meant consistency across templates which makes pages much easier to follow for screen reader users across desktop, tablet and mobile. This is important as different development teams work on different parts of the site so it could have been easy to have a slightly different structure on each page.

Finally we also ensured that all Landmarks were followed by a correctly marked up heading in the content order. iOS VoiceOver, up to and inclusive of iOS6, does not announce the name of the Landmark but instead announces just ‘Landmark’ i.e. ‘Landmark’ not ‘Navigation’. Adding a heading immediately after in the content order means that iOS VoiceOver announces the Landmark and heading as one item giving all Landmarks a unique and understandable name. This bug has since been addressed in iOS7 however coupling Landmarks with headings is still valuable in the site today.

Development

Working in an agile, sprint run environment we then looked at how we could embed accessibility into development. Our goal was to ensure that accessibility was considered part of overall development rather than an-add on. We avoided allocating a single ‘accessibility Sprint’ to do all the accessibility work and instead added user stories and tasks for accessibility into each Sprint as well as included accessibility into acceptance criteria for other relevant user stories or tasks. This was taken from the annotated UX and meant that developers knew up front how best to code a feature.

There were challenges along the way. UX sometimes changed, or new releases in technology meant we had to rethink development. The new iPlayer menu on mobile and tablet, while accessible, is not as usable as it was prior to changes in iOS7 however we are be working to address that.

Fortunately other changes in technology meant other issues were fixed. For example in earlier versions of iOS6 there was a bug where zoomed content would be momentarily cut off when devices were in landscape. Our standards require that pinch zoom is supported which meant the layout would appear broken to some users. This was fixed in iOS6 so we are now able to support people who like to zoom without compromising or breaking the design.

Pinch zoom is enabled within new iPlayer as per the BBC Mobile Accessibility Guidelines

The Standard Media Player

The new BBC iPlayer uses the new BBC Standard Media Player (SMP). The new player offers clearer visual design for buttons, good contrast, keyboard and mouse accessible tooltips. Work has also gone in to improving subtitles; we now have support for different colours for different speakers on catch up content.

The Media Player with subtitles at the top so they are more prominent

We’ve also improved keyboard access as well as labels for screen reader and voice input users. This is a challenge as different assistive technology and browsers have variable support for Flash plus upgrades to browsers and screen reader software can break something that previously worked.

Finally we are testing out the ability to change the size of the player controls to help users with lower vision or mobility impairments. This currently works in Firefox using Control + Shift + P or O and is not a fully-fledged feature yet as we explore more about it.

Standard Media Player also introduces plugins to the playback experience. You can add the programme you’re watching to your Favourites as well as discover more episodes and related programmes from within the player. These features and functionality are available from within the page but obviously make content a lot easier to use when available from within the player. It cuts out the overhead of having to navigate out of the player, find something else to watch, update the page, navigate back to the player and start again. This is an example of how we can make iPlayer not just accessible but also much more usable for disabled users with the introduction of new features which are beneficial to everyone.

You can find out more in our Media Player Accessibility help.

Testing

We submitted the site for third party testing which included expert technical testing as well as usability testing with disabled users. This helped understand better what features people liked and how we could tweak them to make them better. It was useful to see just how much people relied on pinch zoom when on mobile as well as tweak the logic of our headings for screen reader users. Hopefully during the preview, we will gather more feedback that we can work into the designs.

So that’s a quick tour of some of the accessibility work that’s gone into iPlayer.

As iPlayer evolves so will the accessibility. Hearing feedback from you and other users is invaluable and really helps us better understand how to make iPlayer more usable so if you have any comments or questions please post them below or email us at mailto:accessibilityteam@bbc.co.uk.

Henny Swan is Senior Accessibility Specialist, UX&D, BBC Future Media

Introducing the new BBC iPlayer

2014-03-11T09:30:09+00:00

Hello, I’m Dan Taylor, Head of BBC iPlayer and today I’m delighted to share how we are evolving BBC iPlayer for the multiscreen world, starting today with the rollout of a new version for computers, tablets, mobiles and connected TVs.

Just over six years ago, on Christmas Day 2007, we launched BBC iPlayer, offering users the opportunity to catch-up with the last 7 days of BBC programming via their computer.

Fast forward to now and BBC iPlayer is available on over 1,000 different devices and serves 10 million programme requests a day. It now offers more than just catch-up, with live streaming, archive collections, exclusives and premieres. We’ve also introduced innovative new features such as mobile downloads, enabling you to watch offline and on the go, and Live Restart, enabling you to jump back to the start of a programme while it’s being broadcast. It’s a measure of how loved BBC iPlayer now is that it’s the number one brand in the UK according to YouGov’s BrandIndex Ranking.

However there’s always room for improvement and following extensive research and user testing, we are today rolling out a new web version of BBC iPlayer (accessible via bbc.co.uk/iplayer on computers, tablets and smart phones) and a new TV version (accessible via the existing BBC iPlayer app on a range of connected TV devices). The BBC iPlayer mobile and tablet apps will be updated with the new interface in the coming months.

The new iPlayer has been designed for a multiscreen world, so the experience is consistent, but optimised across PC, tablet, mobile and TV devices and we've built it in such a way that we can rapidly develop and release new features across those four screens.

The new BBC iPlayer on tablet, smart phone, TV and computer

The new web version of iPlayer has been developed using responsive design, which means we can deliver the iPlayer experience to multiple different screen sizes without building separate versions. It also means that if I share a link to iPlayer from my computer, it will work just fine if you open it on your mobile or tablet browser.

A major focus of this release is making it easier to find something to watch, helping you quickly and easily find the programmes you know you’re looking for and, crucially, helping you discover something new. The current iPlayer’s pretty good if you know what you want to watch, but we know that 42% of visitors are now coming without a particular programme in mind.

Home screen

With that in mind, we've created a brand new home screen that's simpler, more visual and easier to browse. There’s a consistent navigation bar along the top, providing easy access to channels and categories. There’s a ‘Find tools’ panel, of which more later. However the majority of the screen is dedicated to an image-led browsing experience.

The home screen of the new BBC iPlayer on a computer

Hovering over a programme image provides a short description of the episode along with its duration and when it was first shown - simple information that users have told us they find useful in selecting a programme to watch.

Channels

It’s not just the homepage in new iPlayer which offers this new image-led browsing experience. We've also developed such pages for each of our TV channels, creating a place to discover and enjoy the best those channels have to offer even when they’re off air, complementing the more traditional schedule view.

The CBeebies channel in new BBC iPlayer

Categories

We've created a similar browsing experience for categories and responded to user feedback by replacing the Factual genre with genres which users talk about when describing their TV viewing habits: Documentaries, Food, Arts, History, Science & Nature. These categories showcase the range of catch-up, archive, exclusives and premieres – all forms of TV content in one place.

The Music category in new BBC iPlayer

And it’s not just genres. There are also categories for Audio Described and Signed content and for Northern Ireland, Scotland and Wales, showcasing the best programmes from and about those nations. In addition to the highlights view, each category also offers a full A-Z list, which details every programme in that category.

Collections

Collections are a brand new addition to BBC iPlayer which aid programme discovery by grouping programmes by series, season, event or theme. BBC Four has been releasing themed archive collections for the last few years but they’ve been difficult to find in iPlayer. The new iPlayer enables us to showcase those collections on an ongoing basis.

BBC FOUR Post-War Architecture Collection

Playback

Of course, watching programmes is the beating heart of iPlayer and we’ve optimised the new playback page for what users are looking to do before, during and after viewing.

New playback page

Beforehand, we present all the key information you need to decide whether to watch and provide simple navigation to other episodes from the same series, in case you were after a different one. Once you hit play, we dim the lights and get out of your way.

The new web version of iPlayer makes use of the BBC’s new Standard Media Player which, as well as providing our best ever playback experience across screens, also enables us to develop plug-ins to enhance the playback experience.

For example, if you’re enjoying a programme and decide you don’t want to miss out on future episodes you can now add it to your Favourites without leaving the playback experience.

At the end of an episode, if the next episode in the series is available, we’ll cue it up. We’ll also always offer you suggestions of other programmes you may also like, powered by a new and improved recommendation engine.

Onward journeys from playback

This panel will also include onward journeys to other relevant content on BBC Online, such as BBC iWonder guides.

Find tools

We've not forgotten about the 58% of users who arrive knowing exactly what they're looking for, with the introduction of Find tools.

First, we have the ‘Find a Programme’ box, which not only remembers your recent searches, but also suggests what you might be looking for as soon as you start typing. So, if I type ‘E’ I can get straight to EastEnders.

The Find A Programme box suggests what you might be looking for

Next we have the A-Z Programme List, which does exactly what it says on the tin. We know many users really value the A-Z as a simple way of scanning the full iPlayer inventory.

And finally, a Recently Watched section which remembers what you’ve watched recently so you can quickly and easily resume watching a programme you were part way through or find new episodes of a series you've been enjoying.

Accessibility

Last but by no means least, we’ve invested a great deal of time and effort in making the new iPlayer as accessible as possible. Pages are organised visually into sections with clear headings to ensure both sighted users and blind users with screen readers can navigate content across desktop, tablet and mobile seamlessly. There are also improvements to the Standard Media Player to support users with different set ups including keyboard-only users, screen reader users and voice input users.

Audio description, signed and subtitled content are at the heart of our offering. Subtitles are available on catch-up content via the media player itself (just click/tap the ‘S’ icon) and soon we will soon be adding support for Audio Described and subtitled programmes on mobile and tablet browsers. You can read more about this, and other updates, in our accessibility FAQ.

So, that's a whistle-stop tour of the new product. We've been busy testing it with users and I’m pleased to say that they’ve been telling us its “simple”, “clearer”, “easier”, “more expansive” and “just better”. Critically, they’ve also been telling us that they’ve been discovering programmes they wouldn’t previously have found.

I’m very proud of what the iPlayer development teams in London & Salford have built and as I mentioned, this launch is just the beginning. We've got ambitious plans for later in the year including extending the standard availability window from 7 days to 30 days and introducing new IP only channels (such as a Radio 1 video channel), subject to approval from the BBC Trust. We also have a raft of exciting personalisation features in mind.

Thanks for reading. Please do have a play with the new iPlayer and let us know your thoughts - we’ve created a special survey to capture your feedback.

Also, do look out for blog posts from other members of the iPlayer team over the coming weeks explaining different aspects of developing the new iPlayer.

Dan Taylor is Head of BBC iPlayer, BBC Future Media

New BBC Mobile Accessibility Guidelines

2014-02-25T08:30:10+00:00

Hi I’m Henny Swan and I work in the Accessibility team which is part of BBC Future Media. We provide tools, training, and support to teams within the BBC so that they can deliver web content and applications that are accessible to disabled audiences.

In June last year we published a draft of the BBC Mobile Accessibility Standards and Guidelines. Since then we've been listening to feedback, reviewing the standards and guidelines, and refining techniques so that today the standards can finally come out of draft. To help showcase techniques and best practices we have housed them in their own HTML app with offline storage so they can act as both a reference site as well as a prototype to showcase best practices. You can grab a copy of the BBC Mobile Accessibility Guidelines from the BBC Future Media Standards and Guidelines site.

The Standards and Guidelines are written for BBC.co.uk content developed for UK audiences and for use with the technology commonly available in the UK. They are intended as a standard for BBC employees and suppliers to follow however they can also be referenced by anyone involved in mobile development.

The standards and guidelines are organised into 11 topics. Each is listed with HTML, Android and iOS techniques, examples and evaluation criteria. As accessibility is a shared responsibility there are sections for User Experience, Editors and Developers where roles and responsibilities are defined and a summary of those issues most relevant to the role are listed.

We define standards as best practices that can easily be tested with specific criteria that is not subjective and is technologically possible to achieve with current assistive technology on mobile devices. These are issues that must pass internal tests. Guidelines are best practices that are less testable but considered core to accessible mobile website and apps. As such these should pass tests where possible.

At the BBC we consider accessibility standards and guidelines to be only the first step in delivering accessible experiences for our audiences. We aim to not just make access to news, TV, radio, weather, sport, entertainment and learning accessible but also fun, engaging and above all easy for all our users.

We've evolved the standards and guidelines with a number of apps, Weather, iPlayer, iPlayer Radio, News and Sport, testing out rationale and techniques on web, Android and iOS. The BBC Weather app was built from the ground up with accessibility in mind for both Android and iOS. A lot of work went into focus management and logical content ordering to make complex data for hourly forecasts over 5 days comprehensible to screen reader users and visually easy to follow.

The BBC Weather app on Android and iOS phones

I would love to hear your feedback. Either leave a comment or email us at AccessibilityTeam@bbc.co.uk.

Henny Swan is a Senior Accessibility Specialist, UX&D, BBC Future Media

Future Media Standards and Guidelines Website Refresh

2013-12-11T14:36:53+00:00

If you’re a third party developer who builds services for the BBC it’s likely you will have used the Future Media and Standards And Guidelines website. The site is the home for the BBC’s technical and accessibility standards for web development.

Today Standards and Guidelines has changed. We’ve removed a dozen guidelines that were out-of-date, cross-linked much of the design information to its sister site www.bbc.co.uk/gel, changed the colour and font of the site to bring it more in line with GEL and removed some broken links.

The home page of the refreshed site

Standards and Guidelines is currently built on flat html. The next phase of its redevelopment will be to bring it onto the BBC’s content management system iSite. We’re looking for input both from internal and external developers on suggestions for improvement and the results should be a better looking and simpler Standards and Guidelines launching in spring 2014.

In the meantime if you use Standards and Guidelines and you spot something we’ve missed, please do leave a comment.

Jonathan Murphy is a Senior Editorial Deveelopment Manager in BBC Future Media

Draft BBC Mobile Accessibility Standards and Guidelines

2013-06-18T05:31:01+00:00

Hi I’m Henny Swan and I work in the Accessibility team which is part of BBC Future Media. We support teams within the BBC to ensure they deliver web content and applications that are accessible to disabled audiences.

For the past eighteen months my team have been working hard to improve the accessibility of web content for mobile sites and native apps.

It’s been an interesting journey as there are no internationally accepted guidelines for mobile accessibility so as a result we thought we’d write our own: the Draft Mobile Accessibility Standards and Guidelines which you can find on the Standards and Guidelines section of the BBC website.

Draft Mobile Accessibility Standards and Guidelines

For years BBC teams have used the BBC Accessibility Guidelines to help them build accessible websites. This has proved a useful foundation for mobile accessibility however, we felt we needed something more targeted for device delivery and native applications.

There are differences between desktop only versus mobile web and application accessibility. Take for example colour contrast.

On the desktop web it is widely accepted that a contrast level of 4.5:1 is acceptable. On the mobile web, where users are on the move in changing light conditions dealing with variable levels of glare, it's questionable whether 4.5:1 is enough, so perhaps we should be aiming for something closer to 7:1.

Initially we developed a set of standards and guidelines for HTML, then iOS and Android as these are the platforms we identified most users were accessing content through and also have the most mature accessibility support.

The plan moving forward is to write techniques for additional platforms as and when the need arises, but this doesn’t stop our teams applying these standards and guidelines for Windows Phone, Blackberry and other platforms in the meantime.

By writing three sets of guidelines we laid the groundwork for us to understand where the overlaps between web and native app accessibility are. We then merged the three sets of guidelines into a single set of agnostic standards and guidelines with technology specific techniques.

Maintaining three separate platform specific standards and guidelines would have been a huge overhead and, more importantly, wouldn't have reflected how teams work within BBC where knowledge roles and skills transfer across different teams.

We referenced the Web Content Accessibility Guidelines, platform specific guidelines and other resources that had a good cross over with the mobile web.

We worked with SSB Bart Group, an accessibility software, training and consultancy firm in the States, to develop technology specific techniques to accompany the standards and guidelines. This also includes code samples in HTML, iOS and Android.

Evaluation criteria are also provided for each standard and guideline. We felt it was important for our teams to not just know what to do but also how to do it and how to verify they have implemented guidance correctly.

Each checkpoint is listed as either a ‘standard’ or a ‘guideline’ – the same model that our existing BBC Accessibility Standards and Guidelines use. A ‘standard’ is a checkpoint that must be supported and is testable. A ‘guideline’ is a checkpoint that should be supported, may be subjective and therefore might be less easy to test. This helps our Test team builds in concrete test criteria during Quality Assurance.

While the standards and guidelines have been developed we have been simultaneously building, testing and learning various techniques in making web applications accessible.

Our most notable releases to date include BBC iPlayer on iOS and Android, iPlayer Radio for iOS and Android, the Olympics and Sport iOS and Android apps, and the recent Weather apps.

We have also been integrating accessibility from the start for many responsive products including Barlesque (the header and footer of most BBC web pages and the framework providing core libraries, styles and modules), the TV Channel Home pages and more.

As with the standards and guidelines our apps and web content are a work in progress as we trial new techniques and keep up to date with the capabilities of the technologies and platforms to support accessibility. Our work here is far from done but hopefully we are well on our way.

Tell us what you think

This is a first step. We already have a list of updates that we are making to the standards and guidelines for the next release (which we hope will be soon).

What we’re really interested in however is your feedback so if you have any comments, suggestions, or additions for techniques or evaluation criteria we would love to hear from you either by emailing us or by leaving a comment below.

Henny Swan is senior web accessibility specialist in BBC Future Media.

News Connected Studio

2013-01-08T14:15:34+00:00

Hi I am the head of product for BBC News Online and lead the product strategy and development of website, mobile, tablet and IPTV products for News.

The change of year is a good time to look back and also forward. In the BBC News Online product team in recent weeks we have been reflecting on a year in which we delivered a number of innovative product features to the audience while also planning an exciting event to kick off 2013: our first Connected Studio for News which begins on January 21.

Pages from BBC News Online

With the delivery of our brand new responsive design website, our coverage of events such as the Diamond Jubilee and the US Presidential elections, 2012 was a huge success in News for what we call our 'Four Screen strategy'.

In the UK alone we saw a 28% increase in weekly unique browsers to our websites and applications, the number of tablets accessing our product more than trebled following a massive increase during Christmas week and there has been a 50% increase via smartphones.

Considering that one-third of our users are now not using a desktop PC it is essential that we continue to deliver great experiences across all devices from phones to connected TVs - not only in 2013 but beyond.

This is where Connected Studio comes in.

One thing that is clear to us from talking to the audience and seeing the trends in how people consume news is that in an age of an endless flow of information with access to the news from all the different devices we carry around with us, people increasingly want to more easily find news that is more relevant to them.

It's not that people don't want to see the big major stories that affect us all and the BBC is committed to ensuring it uses its editorial skills to ensure the world is well informed about the things that really matter to the broadest audience.

However, people are increasingly interested in lots of different topics which affect their own personal daily lives and we think we can do a better job in the future allowing you to follow stories that interest you across multiple devices.

So this is the focus of our Connected Studio initiative - discovering ways to consume and distribute news that is more relevant to people. That might be news about where you live or where you work or what happens on the commute between the two places. Or it might be news about the industry you work in, or something that directly affects friends and family. Or just news about your hobbies and what interests you.

We have a great opportunity to build on the systems and products BBC Online built for the Olympics in 2012 and use linked data to describe our content and make it easier to find.

Our journalists are starting to tag stories accurately for the location, people, companies and organisations that they are about and then by linking this data together we will be able to make it possible for you to find and follow the news that affects you.

Where our current local news sites only offer a limited view of the world in those areas, in future we will be able to surface stories about companies who employ lots of people in an area.

Or when an MP has said something in the House of Commons which features on Democracy Live we will be able to show it immediately to people in the area that he or she represents and also to all the people interested in that subject.

We also want to work with the wider media industry to link to other people's content more effectively in the same way.

The Connected Studio is an opportunity for people from outside the BBC to meet up with experts from our teams, to play with our data and develop product ideas and prototypes which we will show to real audiences during the day.

We are hoping to hear from many people across the media and digital industry who would like to get involved and help us with this exciting challenge.

I look forward to seeing many interesting people gathering to help us on January 21 in the heart of the BBC's new journalism headquarters at New Broadcasting House in London. A creative brief for the studio has been published and you can sign up here.

Chris Russell is head of product for BBC News Online.