Alternatives should briefly describe the editorial intent or purpose of the image, object, or element

When alternatives are provided for actionable items such as buttons, and image links the alternative should describe the action that will be performed. For example, "Play" or "Rate this article". Verbose alternatives make content harder to listen to and understand for screen reader users. Avoid the use of 'Image of...'. 'Link to...", 'Picture of...' etc.

The type or trait of an object should also not be described in the alternative as this will be programmatically determined by the screen reader. For example a ‘Play’ button coded as a button with the alternative ‘Play’ will be read as ‘Play, button’. If the alternative is ‘Play button’ the screen reader user will then hear ‘Play button, button’.

iOS

Add concise alternatives via the accessibilityLabel attribute. Alternatives must begin with a capitalised word and must not have a full stop (.). Supplementary information should be provided in the accessibilityHint property. The accessibilityHint property should describe the results of performing the action if the result is unclear.

iOS Example

[aButton setAccessibilityLabel:NSLocalizedString(@"Add to favorites video", @"Add to favorites button accessibility label")]; 

iOS Failure

[aButton setAccessibilityLabel:NSLocalizedString(@"Adds this video to your favorites", @"Add to favorites button accessibility label")];

Android

Use the android:contentDescription property to provide short and concise alternatives. The exception is on EditText fields; these must be coded using the android:hint attribute. This helps users understand what content is expected when the text field is empty. When the field is filled, TalkBack reads the entered content to the user, instead of the hint text.

Android Example

<button android:layout_height="wrap_content" android:id="@+id/sunnyday" android:src="@drawable/blue" android:focusable="true" android:contentDescription="Main Menu"></ImageView>  

Android Failure

<button android:layout_height="wrap_content" android:id="@+id/sunnyday" android:src="@drawable/blue" android:focusable="true" android:contentDescription="Exit this screen and return to the main menu"></ImageView>  

HTML

Use the alt attribute to provide alternatives for images. When providing alternatives for input fields via the title attribute ensure the title attribute is concise and does not supply redundant information such as the name or type of the control or obvious instructions such as "enter text here for".

Tip

Title text is not supported on mobile for links but is supported on form inputs.

HTML Example

<!-- image example -->
<img src="/rating.jpg" alt="Rate this article" />
 
<!-- input example -->
<input id="t1" type="text" title="Username" placeholder="username" />  

HTML Failure

<!-- image example -->
<img src="/rating.jpg" alt="Greyed out stars" />
<!-- input example -->
<input id="t1" type="text" title="Enter your username here:" />   

Testing

Animation content must be sufficiently described in audio and/or text

Description.

iOS

iOS description

iOS Example

iOS Example

iOS Failure

iOS Failure

Android

Android description

Android Example

Android Example

Android Failure

Android Failure

HTML

HTML Description

HTML Example

HTML Example

HTML Failure

HTML Failure  

Testing

Alternative inputs must be supported

Support for alternative input methods aside from touch must also be supported, this could mean external keyboards or braille displays. Users with disabilities may not be able to operate touch screen interfaces. Alternative forms of input and navigation supported by the platform itself must be supported by the application to facilitate the needs of the user.

iOS

The Accessibility API provides alternative input methods for standard touch events. Focus control to elements is provided via theisAccessibilityElement property - this property should be set to YES to allow accessible input.

iOS Example

[_view setIsAccessibilityElement:YES];   

iOS Failure

[_view setIsAccessibilityElement:NO]; 

Android

Developers must ensure that all active elements can receive focus from assistive technology and alternative input methods. This can typically be accomplished by setting the focusable attribute for the field to true. For editable or read-only custom text elements that are developed by extending standard text elements you must ensure a system caret is set to indicate focus for the element.

Android Example

//A text input field that can be accessed directly by touch and is focusable using the keyboard
<EditText android:id="@+id/editTextP" android:inputType="textPassword" android:layout_height="wrap_content" android:layout_width="wrap_content" android:focusable="true"></EditText>

Android Failure

//A text input that cannot be focused using the keyboard
<EditText android:id="@+id/editTextP" android:inputType="textPassword" android:layout_height="wrap_content" android:layout_width="wrap_content" android:focusable="false"></EditText>

HTML

Any HTML gestures must be supplemented with standard navigation methods such as keyboard focus, key presses, links, buttons, or other controls. For example, a drag and drop operation may be supplemented by select elements allowing the user to choose multiple combinations.

HTML Example

<!-- carousel that supports swiping left and right
touch events such as touchstart, touchend, and touchmove are supplemented with keyboard access using buttons, or by watching key presses. -->
<a href="/...">Previous</a>
<a href="/...">Next </a>

HTML Failure

<!-- Gesture monitoring without equivalent keyboard access -->
<script type="text/javascript">
... // perform some action on touch
</script>
...
<div
  ontouchstart="touchStart(event);"
  ontouchmove="touchMove(event);"
  ontouchend="touchEnd(event);"
  ontouchcancel="touchCancel(event);"
></div>

Testing

All color combinations must pass the WCAG 2.0 AA-compliant colour contrast check in accordance with the Snook colour contrast checker.

This is a ratio of 4.5:1 for text 18pt or less in size, and 3:1 for text larger than 18pt or text that is bold and larger than 14pt.

Where it cannot be adapted, stylised text used in pre-existing broadcast logos and branding is exempt from this requirement.

Rationale

If there is sufficient contrast between foreground and background colours, particularly between text and its background but also applicable to the keys of graphs and similar, then users with moderately low vision or with colour deficiencies that affect contrast to a minor degree are more likely to be able to access BBC content without requiring additional assistive technologies.

Techniques

n/a

Tests

All focusable elements must have a clearly identifiable visual style when they have focus

Rationale

Sighted keyboard users do not have the explicit association between pointer and content that pointing device users have, so it is important that they are aware at all times what element currently has focus and which element keyboard interactions will operate on.

The currently focussed element should therefore have a visual style that makes it clearly distinguishable from the surrounding content.

Techniques

Pass:

<style>
    a {
        text-decoration: none;
    }
    a:focus {
        text-decoration: underline;
    }
</style>

Fail:

<style>
    a {
        outline: none;
    }
</style>

Test