From today, we’re rolling out a new look for 麻豆约拍 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 麻豆约拍 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.

> 麻豆约拍 iPlayer - Accessibility

> 麻豆约拍 Technology + Creativity - Accessibility

> 麻豆约拍 R&D - Casualty - Accessible and enhanced audio trial

The 麻豆约拍 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 麻豆约拍 digital products this year:

UX&D and Internal Tools:

The ‘麻豆约拍 for Everyone’ video was published by GEL, along with draft . Neurodiversity . 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 ' 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.

Children’s Games & Apps:

Research relationships continued with  and . It enabled and supported user research for CBeebies, C麻豆约拍 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 麻豆约拍 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.  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 . 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 麻豆约拍’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 麻豆约拍. Accessibility is a key requirement of both the user interface and brand development.

麻豆约拍 Studios:

The commercial arm of the 麻豆约拍 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 #BuildThe麻豆约拍 event open to the public. A heart-warming tale about why accessibility should be considered from the start of a project. Peter also built  in his spare time, a useful Chrome plugin already being used in-house.

Coming Up

Most 麻豆约拍 teams now ‘bake in’ accessibility. Look out for improved universal sign-in and children’s sign-in from 麻豆约拍 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 麻豆约拍 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.

Back then, iPlayer was a catch up service for the 麻豆约拍: 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 . 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 麻豆约拍 R&D has more detail on the audio description studio signal.

The media tools

To do the mixing we use the following tools.

Gstreamer

is an open source multimedia framework that we use with an 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.

BMX

is an open-source project from 麻豆约拍 R&D to read and write MXF file formats in common use at the 麻豆约拍, written by Philip de Nier. It has had many uses in the 麻豆约拍 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.

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 麻豆约拍, 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.

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?

• Audio described content on iPlayer
• “The Audio Describers”: A 麻豆约拍 Radio 4 programme about audio description

Tab ordering between HTML and Flash

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

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

.

Screen Reader and Assistive Technology Support

Screen readers are technologies that 鈥渟crape鈥� 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 鈥楨nter 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.

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 .

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 .

Initialising the Accessibility API

Interacting with the screen reader is done via .

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.

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 .

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.

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.

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.

Example Code

A working example of all of the concepts discussed, or try out our full accessibility implementation using a screen reader on the

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鈥檚 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 麻豆约拍 iPlayer in .

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鈥檇 love to hear your thoughts in the comments below or via the Accessibility email.

Dan Oades is a Senior Software Engineer, Media Playout Team, 麻豆约拍 Future Media

Making the SMP both accessible and usable for disabled users is core to the player鈥檚 success. At the 麻豆约拍 we don鈥檛 just aim to comply with ourbut 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 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.

One subtle benefit of this is that the SMP inherits the colour of the 麻豆约拍 product it is being viewed in so, for example, on iPlayer pink is used. Using the pink for the underline to indicate 鈥榦n鈥� 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 鈥楳ore鈥� panel on mobile).

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.

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 which contains guidance, tips and details about supported software, how to access and possible issues.

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鈥檇 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 . For the 麻豆约拍, 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鈥檝e funded as well as speed up the pace of innovation in a more accessible player that would benefit users beyond the 麻豆约拍. 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, 麻豆约拍 Future Media

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 麻豆约拍 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 麻豆约拍 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 麻豆约拍 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 and and , 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鈥檇 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, 麻豆约拍 Future Media

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 and the

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 麻豆约拍 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.

听

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.

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 麻豆约拍 iPlayer specific requirements for accessibility, above and beyond the 麻豆约拍 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 鈥榤ain鈥� 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 鈥楲andmark鈥� i.e. 鈥楲andmark鈥� not 鈥楴avigation鈥�. 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 鈥榓ccessibility 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.

听

The Standard Media Player

The new 麻豆约拍 iPlayer uses the new 麻豆约拍 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.

We鈥檝e 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鈥檙e 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 .

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鈥檚 a quick tour of some of the accessibility work that鈥檚 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, 麻豆约拍 Future Media

The new web version of iPlayer has been developed using , 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鈥檙e looking for and, crucially, helping you discover something new. The current iPlayer鈥檚 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.

麻豆约拍 screen

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

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鈥檚 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鈥檙e off air, complementing the more traditional schedule view.

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.

And it鈥檚 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 麻豆约拍 iPlayer which aid programme discovery by grouping programmes by series, season, event or theme. 麻豆约拍 Four has been releasing for the last few years but they鈥檝e been difficult to find in iPlayer. The new iPlayer enables us to showcase those collections on an ongoing basis.

Playback

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

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 麻豆约拍鈥檚 new Standard Media Player which, as well as providing our best ever playback experience across screens, also enables us to develop to enhance the playback experience.

For example, if you鈥檙e enjoying a programme and decide you don鈥檛 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鈥檒l cue it up. We鈥檒l also always offer you suggestions of other programmes you may also like, powered by a new and improved recommendation engine.

This panel will also include onward journeys to other relevant content on 麻豆约拍 Online, such as .

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 鈥楩ind 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 鈥楨鈥� I can get straight to EastEnders.

听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鈥檝e 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鈥檝e 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 鈥楽鈥� 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 .

So, that's a whistle-stop tour of the new product. We've been busy testing it with users and I鈥檓 pleased to say that they鈥檝e been telling us its 鈥渟imple鈥�, 鈥渃learer鈥�, 鈥渆asier鈥�, 鈥渕ore expansive鈥� and 鈥渏ust better鈥�. Critically, they鈥檝e also been telling us that they鈥檝e been discovering programmes they wouldn鈥檛 previously have found.

I鈥檓 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 麻豆约拍 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鈥檝e created

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 麻豆约拍 iPlayer, 麻豆约拍 Future Media

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, 麻豆约拍 Future Media

Standards and Guidelines is currently built on flat html. The next phase of its redevelopment will be to bring it onto the 麻豆约拍鈥檚 content management system . We鈥檙e 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鈥檝e missed, please do leave a comment.

Jonathan Murphy is a Senior Editorial Deveelopment Manager in 麻豆约拍 Future Media

For years 麻豆约拍 teams have used the 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 .

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鈥檛 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 麻豆约拍 where knowledge roles and skills transfer across different teams.

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

We worked with , 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 鈥榮tandard鈥� or a 鈥榞uideline鈥� 鈥� the same model that our existing 麻豆约拍 Accessibility Standards and Guidelines use. A 鈥榮tandard鈥� is a checkpoint that must be supported and is testable. A 鈥榞uideline鈥� 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 麻豆约拍听iPlayer on and , and , the and , and the recent .

We have also been integrating accessibility from the start for many responsive products including (the header and footer of most 麻豆约拍 web pages and the framework providing core libraries, styles and modules), the 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鈥檙e 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 麻豆约拍 Future Media.

Pages from 麻豆约拍 News Online

With the delivery of our brand new , our coverage of events such as the and the , 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 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 麻豆约拍 is committed to ensuring it uses its 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 in 2012 and use 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 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 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 麻豆约拍 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 麻豆约拍's new journalism headquarters at in London. A creative brief for the studio has been and you can .

is head of product for 麻豆约拍 News Online.