Unique page/screen titles Must

All pages or screens must be uniquely and clearly identifiable.

The page/screen title is often the first thing people will see or hear and acts as a confirmation of where they have arrived at, helping people orientate themselves within websites and apps. It is particularly helpful for vision impaired users who cannot perceive the whole page/screen at once.

Page titles are standard for HTML. Apps have the facility to add screen titles. However, when visible space is in short supply other means may be used to identify location, such as a logo on a homepage, the first item of content presented as a heading, or a selected tab on top navigation.

Examples

iOS

Provide a concise and descriptive title for each screen of the app. If a NavigationBar is used, for example, set the title of the {coce}UINavigationItem to unique descriptive text.

Android

Set the title of the activity using the setTitle method to a concise and descriptive name.

HTML

Provide unique page titles using the title element that concisely describe the page content. Page titles should generally be the same text as the 1st level heading on the page.

Testing procedures

  1. Examine the title of each page/screen on the site/app.
  2. Verify that a title exists:
    • For HTML a unique descriptive title element must be present be announced by a screen reader;
    • For Android and iOS a title must appear at the top of the screen and be announced by a screen reader.

Testing results

The following checks are true:

  • For HTML a unique descriptive title element is present and announced by a screen reader;
  • For Android and iOS a title appears at the top of the screen and is announced by a screen reader.

Headings Must

Content must provide a logical and hierarchical heading structure, as supported by the platform.

A good heading structure enables people to scan a page/screen quickly and understand the structure of the content. Screen reader users can also use headings to quickly navigate within a page or screen.

Headings are standard for HTML, and available on iOS since iOS6. Android does not have a way to distinguish headings programmatically, however some elements, such as tables and listviews, do have headers.

Examples

iOS

Explicit headings are only available in version iOS6 and later and can be assigned by using the UIAccessibilityTraitHeader. Aside from that headers are available in UITableView, UINavigationBar and content displayed via a web view.

Android

Headings are not available. Explicit headers are provided via the HeaderViewListAdapter which is only available to list views.

HTML

For responsive sites think carefully about the use of headings if content is reduced on mobile. For example, on desktop a heading may be given with an image and some brief text. On mobile this may collapse down to the heading and image, which may work better as a list across both desktop and mobile.

Other things to consider, in order to make headings more usable for screen reader users:

  • Lists and headings used together to mark up content should be avoided;
  • Headings should be coded around content that doesn’t change, i.e. a category name such as ‘COMPANY NAME News’ rather than a news item that will update frequently;
  • Headings should not overwhelm a page as this can undermine their usefulness for screen reader users when navigating, a maximum of 7-9 headings should suffice.

Testing procedures

  1. Activate a screen reader.
  2. Examine each page/screen and locate any visual headings/headers.
  3. Determine if headings/headers are possible in the platform.
  4. Verify that there are actual heading/headers.
  5. Verify that headings/headers are announced by a screen reader.
  6. Verify that all headings are logically structured. This is for HTML content only.

Testing results

The following checks are true:

  • All visual heading/header elements are represented as headings/headers (within the limited imposed by the platform);
  • All headers are logically structured (HTML content only).

Containers and landmarks Should

Containers should be used to describe page/screen structure, as supported by the platform.

The visual layout of a page or screen groups elements to help people understand the structure of the content. Containers help assistive technology, such as screen readers, to describe groups of elements so that people who cannot see the visual layout can also understand the content structure. Screen reader users can also use containers and landmarks to quickly navigate within a page or screen.

Semantic structural elements and/or ARIA landmarks are available for HTML. Structural containers are available for native apps.

Examples

iOS

Use standard iOS navigational and structural views. Use of these views will allow for navigation using containers with a screen reader. Use UINavigationBar, UITabBar and other standard navigational structures.

Android

Not applicable for native apps. Android accessibility only interacts with a single element at a time and does not have a mechanism to navigate by container and does not indicate entrance or exit from containers.

HTML

Use ARIA landmark roles or HTML5 sectioning elements to describe document structure and outline different parts of the page, such as navigation, main content and footer info.

Landmark roles include: banner, navigation, search, main, complementary, article, section, and contentinfo.

Equivalent HTML5 elements include: header, nav, main, aside, article, section, form, and footer. These elements have default landmark roles and do not require an ARIA role attribute to be set.

For more information refer to the W3C HTML5 Sectioning Elements: ARIA Landmarks Example.

Testing procedures

  1. Activate a screen reader.
  2. Verify that containers are used to structure the page:
    • For HTML pages these must be appropriate sectioning elements, or non-semantic containers with an ARIA landmark role, for each part of the page that has an equivalent ARIA landmark,
    • For HTML pages in mobile Safari each part of the page that has an equivalent ARIA landmark must be navigable by selecting 'Landmarks' in the Rotor menu.
    • For HTML pages in mobile Chrome each part of the page that has an equivalent ARIA landmark must be navigable by selecting 'Headings and landmarks' in the Local context menu.

Testing results

The following checks are true:

  • The page is structured with appropriate containers:
    • HTML pages announced appropriate containers for each part of the page with an ARIA equivalent landmark;
    • iOS pages containers could be navigated to as landmarks;
    • Android pages containers could be navigated to as landmarks.

Grouped elements Must

Controls, objects and grouped interface elements must be represented as a single accessible component.

It is easier and quicker for people using a keyboard or screen reader to interact with content when not overwhelmed and confused by extraneous elements. Grouping elements into a single overall control makes things clearer, simplifies interactions, and can provide larger touch targets.

For example, a control such as a custom item selector may be made up of smaller interface elements, but will be easier to use if conveyed as a single control. Another common example is grouping adjacent links to the same resource.

Jump to:

Examples

Testing

Advanced

Examples

iOS

Disable accessibility for visual elements such as labels that are represented elsewhere such as an accessibility label for a control element.

Android

Group items into a single target container.

HTML

Where possible use standard controls rather than custom controls. HTML elements can be grouped using ARIA roles and attributes such as tablist, as well HTML 5 structures such as figure or fieldset. Group related elements inside a single link element. Whereas links representing tree nodes in HTML should be grouped using a single link element when only one action is expected of the tree node, e.g. expand/collapse.

Testing procedures

  1. Activate a screen reader.
  2. Identify all compound object, elements and controls on a page.
  3. Verify that compound objects, elements, or controls are announced as a single unit where applicable e.g. a slider control should be indicated as a slider rather than as an up button, a down button, and an indicator.

Testing results

The following check is true:

  • All compound element, objects, and controls do not indicate individual elements but rather announce themselves as whole unit.