1.1 This standard defines the steps you MUST follow in order to ensure that any games used on BBC sites are as accessible as reasonably possible to your audience.
1.2 The requirements of this standard apply to games only. For all other multimedia accessibility requirements please see the Multimedia Accessibility standard. If you find any conflicting information betwen this standard and the Multimedia Accessibility standard, the information presented here MUST be followed for games.
1.3 All games are challenging in some way, therefore may not be accessible to our entire audience. Bear in mind that games that rely on multiple areas of skill can prevent multiple groups of users from accessing your content, reducing reach. Try to ensure that your proposition does not exclude any group unnecessarily.
2.1 In this document we use the following definitions:
3.1 There are four areas of skill that relate to games – motor, cognitive, vision and hearing. You MUST NOT exclude those who have a disability relating to any of these four areas unnecessarily.
3.2 If you believe the editorial proposition is such that your game will be inaccessible to any of the four groups then you MUST submit an exemption request to Editor, Standards & Guidelines for advice at the start of the project, before any build commences. Justifiable reasons for exemptions might include considerations such as: music games not being able to be made meaningfully accessible to deaf people; however there is no justification for excluding other groups through the use of complex controls or wordy instructions.
Making games accessible to players with vision related disabilities means avoiding reliance on colour or small text and considering the size of icons and text.
4.1 You MUST comply fully with the Use of Colour and Colour-Contrast standard. In particular:
4.1.1 You MUST ensure that all colour contrast registers as AA via this tool: snook.ca; this is essential for all text, icons and critical gameplay elements.
4.1.2 You MUST NOT convey key information by colour alone. Colour MAY be used only to reinforce other methods, for example use a green tick rather than just the colour green to signify a correct answer.
4.1.3 You MUST NOT convey key information by reference to colour, for example ‘click on the red button to continue’.
4.2 If using a technology that does not take into account browser font preferences, such as Flash or Unity, text MUST be at least 13px (13pt in Flash).
Making games accessible to players with hearing related disabilities (and also the many players who do not have sound available due to technology or environment) means providing information conveyed using sound by alternative or additional means, e.g. subtitles.
5.1 You MUST ensure the game can be played without sound, by ensuring any key information (information required to be able to play) delivered using sound is also conveyed visually, by eg. icons, diagrams, text (subtitles) etc.
5.2 You MUST include a mute button and volume controls.A1
Making games accessible to players with cognitive related disabilities means making them clear and simple to understand, and avoiding distractions or sudden changes.
6.1 You MUST NOT cause any content to flicker at a rate greater than 3 times per second.
6.2 You MUST use as simple and clear language as possible.
6.3 You MUST ensure that all text that runs over 3 or more lines is left-aligned, and that line width does not exceed 70 chars inc. spaces.
6.4 You SHOULD avoid fast or repetitive movements where possible.A2
Making games accessible to players with motor related disabilities means ensuring that gameplay is not reliant on precise timing or movements, and supporting alternative control methods. Catering for motor disabilities is the most challenging type of game accessibility consideration, with many subtleties.
7.1 You MUST build your game so that it can be controlled using the keyboard, which has simpler motor demands than a mouse. This MAY be offered either as the sole control method, as an alternative, or as an addition.
7.2 You MUST include a logical tabbing sequence for all menus, and allow browsing by both tab/return and cursor keys. This will support both keyboard and some assistive technologies.
7.3 If using Flash you MUST implement tab sequence using
.tabindex (within Flash). This will then automatically support cursor key access.
7.4 You MUST ensure that any off-screen objects move on-screen when tabbed to.
7.5 You MUST keep controls as simple as possible, avoid using multiple key control functions and very precise clicking or dragging; try to rely on as few keys as possible.
7.6 You MUST ensure that interface elements remain stationary when they need to be selected, or provide either a pause button or a static alternative.
|30/07/2010||v1.0||New standard. This standard applies to use of games only.||Ed Lee|
Like all other Future Media Standards & Guidelines, this page is updated on a regular basis, through the process described on About Standards & Guidelines.
This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.