Multimedia Accessibility Standards v1.0
1. Purpose
1.1. This document defines the standards you MUST adhere to in order to ensure that any multimedia technologies used on BBC sites are as accessible as possible to all of our audience.
1.2. It includes information about multimedia technologies commonly used on bbc.co.uk, such as Flash, and others that may become more commonly used, such as Silverlight and Adobe Air.
1.3. It replaces the Flash Accessibility Standards.
2. Definitions
2.1. In this document, we use the following definitions:
- A "Flash movie" is the SWF container you put on an HTML page, as based on Adobe’s definition. For further information refer to the Adobe website.
- A "Flash object" is an item contained within a Flash movie; for example, a video clip (.flv file) or button.
- An "asset" is an independent content element that can be used to make, for example, a Flash movie, or a javascript application. In a Flash movie assets would include the images, the audio, and the video.
- A "rich media object" is an object embedded in a page that contains any combination of moving or updating text, forms, animated graphics, audio, video, or animation. It is published using a plug-in technology, or JavaScript.
3. Other relevant standards
3.1. Although you MUST ensure that your site complies with all BBC standards and guidelines on this site, the following are particularly pertinent when developing multimedia sites:
- All accessibility-related standards and guidelines
- JavaScript Standards
- Third-Party Hosting Requirements Standards
3.2. If there are areas of your site that do not comply with standards you MUST submit an exemption form to the Editor, Standards & Guidelines for consideration by the working group responsible for that standard.
4. Assessing your choice of technology
4.1. Before you decide upon a specific technology, ensure that you have consulted technical staff in your decision. In addition, refer to Assessing Which Technology to Use For Immersive, Rich, Multimedia Proposals. This document provides guidelines on how to decide which multimedia technology is suitable for your site’s editorial proposition.
4.2. You MUST apply for an exemption for any technology that is inaccessible to a particular audience.
4.3. If your exemption request is approved then you MUST also provide an accessibility statement on your site from launch that explains the reasons why you have chosen the technology.
4.3.1. The accessibility statement MUST be approved by the Usability and Accessibility Team in Central UX&D, and you will need to allow the team at least three weeks to do this. The team will also be able to advise you on where best to position the statement on your site.
4.4. If you wish to use a technology on your site that is not covered in this or any other standards on the Standards & Guidelines website you MUST refer to the New Technologies Register [
this is an internal BBC website – please gain access through your Technical Account Manager] to see whether any other sites have used it previously, considering the following:
4.4.1. If a technology that you want to use has been assessed and deemed suitable for use on BBC sites (*.bbc.co.uk), you MUST only use it in the same way that it was used when assessed. Contact the Editor, Standards & Guidelines for advice.
4.4.2. If no other site has used the proposed technology you MUST contact the Editor, Standards & Guidelines for an exemption to use it before progressing.
4.4.3. If the exemption request is accepted, you MUST complete and return the New Technology Proposal template to the Editor to enable the Future Media & Technology group to capture valuable information about its usage and deployment.
4.5. You should also bear in mind that difficulties with implementing your choice of technology are not necessarily limited to disability-related accessibility; for example, machines in libraries or schools may not be able to access content delivered through the latest versions of various plug-ins. For guidance, contact the Editor, Standards & Guidelines.
4.6. Further information about providing accessible multimedia websites is given in Appendix A below.
5. In general
5.1. Flash MUST always be embedded using JavaScript, so if a user doesn't get the JavaScript, then they also don't get the Flash.
- This is to enable progressive enhancement of the page: everyone can access the basic content and functionality of the web page, using any browser or Internet connection, whilst also allowing those with better bandwidth or more advanced browser software an enhanced version of the page.
5.2. Any Flash website MUST have an HTML equivalent for its core content. This is to ensure that, regardless of technology, all types of audience can get to the editorial proposition of the website.
5.3. A visible, accessible HTML link MUST be provided wherever there is an alternative to a Flash site or movie.
5.3.1. Users MUST be able to access the non-Flash alternative, even if they have Flash installed.
- This is to allow users to choose whether or not they want to use the Flash version, and also to provide site robustness in the event of errors.
5.4. In accordance with the BBC’s principles of separating content from presentation, you SHOULD store objects outside the Flash movie. This is so that the objects can be used by other technologies that may be more accessible.
5.4.1. For example, although Flash Lite content works on some mobile platforms, PC or Mac-based versions of Flash content currently do not work on any, which means that none of our sites developed using these versions can be accessed using a mobile internet browser. However, if the objects displayed using Flash are stored separately they can be repurposed for use on mobiles.
5.5. You MUST include a visible and accessible mute button for any rich media objects that contain audio, including during download. This is so that people who are already playing audio, such as the radio, can turn off the audio in your application.
5.5.1. You SHOULD also include accessible volume control functionality if you are not using the EMP to display A/V content on the site (the EMP already includes accessible volume controls).
5.6. You MUST NOT remove the default functionality provided in the context (right-click) menu. This is so that users can always access, for example, the zoom controls.
5.7. All graphic interface elements MUST comply with the Colour Contrast Standards.
5.8. You MUST NOT cause the page containing a rich media object to auto refresh. When a page auto refreshes it forces a screen reader to begin reading from the top of the page again.
6. Movement and clickable content
6.1. In general, you MUST ensure that any rich media content on your pages complies with the standards on movement and flicker in the Accessibility Guidelines.
6.2. In particular, you MUST allow users to:
- Pause or permanently turn off any distracting movement on the page that is not deliberately initiated by the user. For example, see the animated backgrounds on the CBBC website; and
- Freeze all clickable content, such as menu items and buttons UNLESS this clickable content forms part of a game that doesn't make sense if you allow it to be frozen. For example, see the Charlie and Lola germ counting game on the CBeebies website.
This will enable users with motor or cognitive difficulties to have better access.
7. Keyboard requirements
7.1. All keyboard access controls MUST comply with the clauses in the Keyboard Access Standard.
7.2. Where suitable, a scanning single-switch option may also be beneficial for users with severe physical or cognitive impairments.
8. Text equivalents
8.1. All text equivalents MUST comply with clauses in the Textual Equivalents Standard.
9. Flash cross-promotional banners
9.1. Flash cross-promotional banners are those that promote other areas of BBC sites from a webpage; for example, a banner on the EastEnders website that advertises the Football Player application on the Radio 5 Live website.
9.2. There MUST be an HTML equivalent to each banner.
9.3. Animations MUST stop after a maximum of two loops.
9.4. All banners MUST comply with the Flicker Standards.
9.5. Additional functionality such as expanding panels including surveys or competitions MUST NOT be triggered by a mouse over, and MUST be launched by clicking (or equivalent action) the banner.
9.6. Additional functionality MUST be available as a text equivalent.
Appendix A: Making the multimedia accessible versus providing an alternative
10.1. You must consider the needs of all disabled audiences for your multimedia content.
10.1.1. If used appropriately, multimedia technologies, such as Flash, allow production teams to create rich experiences which support the needs of many disabled people.
10.1.2. However, many multimedia technologies provide challenges in making materials which are accessible for some audiences. For example, here are the options available to you when making sites accessible to blind users:
- Try and make the multimedia content accessible for blind users. Either:
- Concentrate on making sure it supports screen readers well, using the technology’s accessibility guidelines. See the tutorials on the Adobe website for advice on making Flash work well with screen readers; or
- Make the content "self voice". If considering this option you should contact the Accessibility and Usability team for advice. Self voicing is more than just ensuring the words on the screen are read out to blind users; it’s about giving an experience to a blind user that allows them to understand the resource and gain its editorial values.
- Provide an equivalent alternative to the multimedia content, which gets across its editorial values in a way that is accessible to blind users. Traditionally, this is normally done using HTML, but other technologies which screen readers can easily make accessible could be used.
10.1.3. You should contact the Usability and Accessibility Team in Central UX&D for advice on which one of these options is most appropriate for your project and, as stated in section 4.2. above, you MUST apply for an exemption if it is not reasonable to implement one of the options in 10.1.2. above.
11. Document history
| Date | Version | Change | Author |
|---|---|---|---|
| 24/11/2008 | v1.0 | First version of the standard. | Victoria Jolliffe, Accessibility Working Group |
Document editor: Editor, Standards & Guidelines. If you have any comments, questions or requests relating to this document, please contact the Editor, Standards & Guidelines.
Like all other Future Media Standards & Guidelines, this page is updated on a regular basis, through the process described on About Standards & Guidelines.
© MMIX