Alternatives for non-text content Should

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

People using screen readers are often vision impaired and unable to perceive non-text content. Providing a brief alternative that the screen reader speaks conveys the same editorial intent or purpose of editorially significant non-text content, such as buttons, icons, images, or avatars.

When alternatives are provided for actionable items such as buttons, or image links, the alternative should describe the action that will be performed. For example, a button with a triangle icon is often used to play content and the alternative would be "Play …".

If there are several similar items on the same page/screen, each should have a unique alternative to distinguish them from each other. For example, rather than multiple 'share' buttons with the same alternative "Share", the alternative should be "Share ..." and include the name of the related item.

Verbose alternatives make content harder to listen to and understand for screen reader users. Endeavour to be succinct, and avoid redundant phrasing such as "Picture of ...", "... logo", or "Select this to ...".

The element type or trait, such as image or button, does not need to be included in the alternative as it is programmatically determined and added by the screen reader. For example, a 'play' button coded as a button with the alternative "Play button" would be spoken as "Play button. Button.". An image coded as an image with an alternative beginning "Image of ..." would be spoken as "Image. Image of ...".

Examples

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.

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.

HTML

Use the alt attribute to provide alternatives for images. Title text is not supported on mobile for links and only partly supported for form inputs, so don't use them. When providing alternatives for input fields via the aria-label attribute, when it is not possible to use a label, ensure the text is concise and do not supply redundant information such as the name or type of the control or obvious instructions such as "enter text here for".

Testing procedures

  1. Activate a screen reader.
  2. Identify any meaningful images, elements, or objects.
  3. Verify that an equivalent alternative briefly describes the intent of the functionality.
  4. Verify that words such as “image of”, “picture of”, “link to” are avoided.

Testing results

The following checks are all true:

  • Each meaningful image has an alternative that briefly describes the intent and is announced properly;
  • Each alternative does not contain words such as “image of”, “picture of”, or “link to”.

Decorative content Must

Decorative images must be hidden from assistive technology.

Hidden or inactive content that is, for example, behind other content such as a pop-over or side-drawer, should not be navigable for users of assistive technology as they may think they can interact with this content.

This can be achieved by setting the appropriate properties or states on an element or object, so assistive technology is informed that it is off-screen, obscured, or hidden.

Examples

iOS

UIView, UIControl, and UIImageView objects along with any custom objects descended from these are not accessibility enabled by default. Other UI elements such as UIButton and UILabel are accessibility enabled and must be accessibility disabled if they are not meant to be accessible.

Android

Developers should ensure that elements that do not convey meaning or information to a user are not focusable via the android:focusable property.

HTML

For images, provide alt text that is null ({code)alt="") or CSS background images. For input fields not meant for the user, use the attribute type="hidden" . For other inactive buttons and elements set the disabled attribute. For obscured or off-screen content, use aria-hidden="true" and tabindex="-1".

Testing procedures

  1. Activate a screen reader.
  2. Locate any images, objects, or elements that do not have meaning, are visibly disabled, or appear obscured.
  3. Attempt to move focus or navigate to these images, objects, or elements.
  4. Verify that the images, objects, or elements do not receive focus and are not rendered by a screen reader.
  5. If the images, objects, or elements can be navigated to, ensure that they are announced as "unavailable" or "disabled" and verify that they are not actionable.

Testing results

Either of the following checks must be true:

  • Images, objects, or elements that are not meaningful do not receive focus and are not read by screen readers;
  • Images, objects, or elements that are not meaningful yet do receive focus are announced as "unavailable" or "disabled" and are not actionable.

Tooltips and supplementary information Must not

Tooltips must not repeat link text or other alternatives.

Not all users will see tooltips so they must not include essential information.

Hints, titles and other tooltip-like text should provide additional explanatory content rather than repeat the main alternative for an element, object, or image. This prevents duplication of information for screen reader users.

Jump to:

Examples

Testing

Examples

iOS

Key recommendations are:

  • Assign a 'hint' to an element with the expanded text via xCode;
  • Hints must start with a verb and omit the subject;
  • Hints must begin with a capitalised word and not end in a full stop (.);
  • Hints must not contain the name of the type of control or view (i.e. button) as the user is informed of this via the trait attribute;
  • Hints must not include the name of the action or gesture as these may become out-dated with different versions of OS.

Android

Android does not provide tooltips or additional hint text other than aria:contentDescription . Note however that tooltips can be shown when long-pressing on icons in the Action Bar.

HTML

Key recommendations are:

  • Do not use the title attribute as title is not well supported on mobile;
  • Do not rely on ARIA tooltips, as while there is some support on iOS there is not much across other devices or platforms;
  • Do not use title attributes and explicit labels together.

Testing procedures

  1. Activate a screen reader.
  2. Gain focus on the individual objects, elements, or controls.
  3. Ensure that identity, information is not announced twice for each individual item (e.g. “Next Next button”).

Testing results

The following check is true:

  • Information provided via a screen reader for an object, element, or control is not announced more than once, including accessibility properties which are conveyed via speech such as identity of the item.

Roles, traits and properties Must

Elements must have accessibility properties set appropriately.

Users of assistive technology, such as screen readers, rely on accessibility properties such as role, name, value, and state to be set appropriately in order to know how to identify and interact with an element or object.

For example, on iOS a trait of 'button' must be set in order for a VoiceOver user to know what the element does and how to interact with it. With HTML content, if a user hears "button" they know to use the Enter key, if they hear "link" they know to use the Space Bar.

Standard elements generally provide roles, traits and properties by default within the platform. Custom elements and objects will require all accessibility roles, traits and properties to be set.

Jump to:

Examples

Testing

Advanced

Examples

iOS

Add traits, UIAccessibilityTrait, to custom elements to describe behaviour (type/role) and/or state. An object can have more than one trait which includes: Adjustable, Button, Link, SearchField, Heading, Keyboard Key, StaticText, Image, PlaysSound, KeyboardKey, Selected, SummaryElement, UpdatesFrequently, NotEnabled, None, StartsMediaSession, AllowsDirectInteraction, CausesPageTurn . The accessible name should be set via the accessibilityLabel and any supplementary description information via accessibilityHint.

A full list of Traits and their purpose can be found in the Apple Developer Guidelines.

Android

Roles are provided for standard widgets and extensions of standard widgets. Custom widgets must us contentDescription to provide role information. The Android platform does not provide an equivalent to HTML5 or ARIA roles or accessibility traits like the iOS platform.

HTML

When available use standard HTML controls. For example a button must be coded as a button and not an image using CSS and JavaScript. When standard HTML controls do not exist (and only then), use generic HTML elements and provide equivalents via WAI-ARIA and via a method that does not require ARIA.

Testing procedures

  1. Activate the screen reader.
  2. Gain focus on the individual object, element, or controls.
  3. Verify that the announced item label matches the on-screen text or contains additional supplementary information to assist with non visual access of the item.
  4. Verify that the announced role of the item matches the perceived visual role.
  5. If applicable, verify that the value of the item is properly announced by the screen reader.
  6. Verify that the state of the element is announced properly.
  7. If applicable, toggle the state of the item and verify that the screen reader announces the correct state change.

Testing results

The following check is true:

  • Object, elements, or controls including their labels, roles, values, states and state changes are correctly announced by a screen reader.

Visual formatting Must not

Visual formatting alone must not be used to convey meaning.

People who are vision impaired may not perceive visual formatting, such as size, shape, location and colour, or attributes such as bold and italics.

Visual formatting must not be the sole method of communicating information. Provide non-visual alternatives, such as semantic code, hidden text or accessibility labels. In particular, alternatives for predominantly visual components, such as maps, charts, and infographics, will need to suitably represent information in a non-visual way.

Examples

iOS

Use accessible traits or labels to convey meaning that is also conveyed visually through visual presentation.

Android

Include any information conveyed by formatting in the accessible name of the element. This can be done by setting the contentDescription attribute for the field.

HTML

Semantic mark-up such as strong, em, etc. should be used over purely visual formatting using CSS to indicate meaningful aspects such as text formatting. Additionally, structures such as lists, and headings should be used to indicate relationships of items.

Testing procedures

  1. Activate the app.
  2. Determine if any component is using visual formatting to convey meaning, including:
    • Colour,
    • Shape/size,
    • Font attributes (bold/italics, etc.),
    • Location,
    • Orientation,
    • Selection.
  3. Determine if on-screen text, alternative text or audio cues are present that supplements the visual formatting:
    • Navigate to the item with a screen reader to confirm alternative text;
    • Visually verify the presence of on-screen text.

Testing results

The following check is true:

  • When an object, element, or control uses visual formatting to convey meaning, on-screen text, alternative text or audio cues are also provided.
  • What you see is what you should hear.
  • All semantic elements must be pronounced properly.