Introduction

iOS Native Mobile App Accessibility

The iOS platform features a wide range of accessibility features for a wide range of disability types. It was the first mobile operating system for smart phones and tablets to offer a robust touchscreen interface and screen reader for users who are blind.

The accessibility API is sophisticated, approaching the accessibility support in desktop operating systems or in web content, though often in a simplified way. For example, iOS allows developers to create headings, but unlike in HTML, iOS does not allow headings to be given levels or to be organized in a hierarchical structure. Similarly, iOS does not distinguish between buttons and links. Both are treated as buttons.

Even within the simplified nature of the iOS accessibility model, it is possible to create highly accessible native iOS applications by following the same general principles common to all digital accessibility. In the end, all digital content must follow the same four principles outlined by the World Wide Web Consortium in the Web Content Accessibility Guidelines (WCAG) 2.0:

  1. Perceivable — All content must be available to users through whichever senses they can use: sight, sound, or touch.
  2. Operable — People must be able to interact with the content and interface using the methods they are able to use (e.g. mouse, keyboard, touch, voice, and alternative assistive technologies).
  3. Understandable — Users must be able to comprehend the content, interface, and interactions.
  4. Robust — The interface and content must be designed to be compatible with current and future technologies, taking into account coding best practices and the accessibility API.

Summary

This training summarizes many of the concepts taught in the full web accessibility training, in a way that makes the concepts relevant to iOS developers. It can still be useful to learn the details of web accessibility (HTML, CSS, JavaScript), because of the way that iOS applications frequently include web content.

The iOS platform is rich with accessibility possibilities. It does have some limitations in comparison to the accessibility capabilities of full-featured desktop systems, but it comes with the advantage of being able to carry around an accessible mobile computer in your pocket or hand bag. Mobile device accessibility is one of the most powerful enablers of independence for people with disabilities, but only if the apps have been designed with accessibility in mind. It is up to the design and development team to take advantage of the accessibility possibilities in the iOS development environment.

Resources

Deque University

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

iOS Accessibility Features

Checklist - Deque

Category

None documented

Download Summary & Checklist

IOS: Accessibility features

Accessibility features for iOS7+ include:

  • Sir- voice search
  • Text size
  • VoiceOver - speech output
  • Invert colours
  • Speak selection
  • Speak auto-text - automatically speaks auto-corrections and auto-capitalisations
  • Larger Type
  • Bold Text
  • Increase Contrast
  • Reduce Motion
  • Hearing Aid support
  • Subtitles and Captioning - customise and style your own subtitles
  • Mono Audio
  • Noise Cancellation
  • Adjust Volume between Right and Left Channels
  • Guided Access
  • Switch Control
  • Assistive Touch
  • Home-click Speed
  • Accessibility shortcut - map features to the Home Key

VoiceOver

iOS VoiceOver supports explore by touch and gestures. When in web pages or in an app you can use a gesture like turning a dial to bring up a Web Rotor. This is a list of options that you can choose to navigate by - it's similar to how you may navigate by headings, lists or WAI ARIA Landmarks using a desktop browser such as Jaws, NVDA or Voiceover on Mac. A great way of testing how accessible content is for VoiceOver users is to switch off the screen and use screen curtain. You can switch off the display by triple tapping the screen with three fingers.

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

User Interaction

Checklist - Deque

Touch Target Size

  • The click/touch target size SHOULD be large enough (without using zoom) to facilitate easy use with a finger, without risking activating an adjacent link or button.

Target Spacing and Grouping

  • Touch targets MUST NOT overlap.
  • Compact touch targets SHOULD NOT be immediately adjacent to each other.
  • Active elements with the same target SHOULD be grouped into one touch target.

Activate on Release

  • Touch controls MUST NOT activate when an item is first touched.

Kinetic/Accelerometer

  • An application MUST NOT rely on kinetic motion (detected by the accelerometer) alone.
  • The user SHOULD be able to disable motion-sensitive features.

Voice

  • An application MUST NOT rely on voice control alone.

Gestures

  • An application MUST NOT rely on gestures alone.
  • Whenever possible, actions SHOULD be mapped to their corresponding default iOS gestures.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

UI Controls

Checklist - Deque

Buttons

  • A button MUST always convey its role using the correct trait.
  • An active image used as a button MUST convey the correct role.
  • When a button is disabled it MUST convey its state.

Links

  • The role and purpose of a link MUST be clearly conveyed by VoiceOver.

Progress Bar

  • Progress bars MUST convey their visible name to VoiceOver users with a descriptive, unique accessibility label.
  • Progress spinners (UIActivityIndicatorView) MUST speak correct alternative text or immediately receive focus in order to convey an accessible name to VoiceOver users.

Slider

  • Slider controls MUST have a visible label that is programmatically associated using the accessibility label property.

Switch

  • Switch controls MUST have a visible label that is programmatically associated using the accessibility label property.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Notifications

Checklist - Deque

Notifying Users of Changes

  • Dynamically generated content following user interaction MUST meet one of the following: assistive technology is automatically made aware of the new content OR the new content is the very next thing the assistive technology will encounter on the page.

Time Limits

  • If there is a session time limit, users MUST be warned before the session ends and MUST be given time to save their data and/or extend the session.
  • Incomplete data SHOULD be saved after a session timeout.

Alert

  • Alerts MUST include a title and description.

Dialog

  • Custom Dialogs MUST set accessibilityViewIsModal to "true" and the focus MUST be sent to the dialog.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Custom Elements

Checklist - Deque

Accordion

  • Accordion components MUST announce their accessible name and their expanded or collapsed state.

Autocomplete

  • VoiceOver users MUST be automatically made aware of the autocomplete suggestions when they appear.

Rating

  • A rating control MUST always convey its current value, any visible information, and be operable by both VoiceOver and non-VoiceOver users.

Sortable Table

  • If a table is sortable, the header cells' accessibility labels MUST dynamically update to correctly convey their sorted state each time the data order changes.

Toggle

  • Toggle buttons MUST convey an accessible name with programmatically associated, visible labels and convey their state using the accessibility label.
  • Image toggle buttons MUST have descriptive, accurate alternative text provided in the accessibility label.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Form Labels and Validation

Checklist - Deque

Labels

  • The label MUST be visible at all times.
  • Labels MUST be programmatically associated with their corresponding control elements.
  • A "hint" SHOULD be provided when the label doesn't sufficiently convey a control's purpose to VoiceOver users.

Group Labels

  • For groups of related controls where the individual labels for each control do not provide a sufficient description, additional group labels MUST be provided.

Checkboxes

  • Checkboxes MUST convey their selected or checked state to VoiceOver.
  • Groups of checkboxes MUST provide a common group label as well as a unique label for each control via their accessibility label properties.

Date Picker

  • A standard Date Picker control SHOULD be used instead of a text field in order to avoid forcing users to enter a date with a default keyboard.

Radio Buttons

  • Radio buttons MUST provide a common group label as well as a unique label for each control via their accessibility labels and they MUST convey their selected state.

Select (UIPickerView)

  • Controls using UIPickerView MUST be programmatically associated with their visible label in order to provide an accessible name.

Text Fields

  • Text fields MUST have programmatically associated, visible labels.

Validation and Error Reporting

  • Efficient, intuitive, and clearly identified text based alerts MUST be provided to users for form validation cues and errors.
  • If input errors are automatically detected, suggestions MUST be provided in text for fixing the input in a timely and accessible manner before the data is submitted to the server.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Device Orientation

Checklist - Deque

  • The orientation of the content MUST not be locked to either landscape or portrait unless a specific orientation is essential for the functionality of the app.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Semantic Structure and Meaning

Checklist - Deque

Headings

  • Headings used to title or describe sections of content MUST use the header trait in order to convey their semantic purpose.

Tables

  • Data tables MUST have the correct reading order, MUST convey the row and column header text for each data cell, and MUST correctly associate the data cell with the header cell in the accessibility label.

Reading Order and Focus Order

  • The reading order of a screen as conveyed by VoiceOver MUST be logical and intuitive.
  • When content is added or deleted from a screen, VoiceOver focus MUST be managed logically and never be lost.

Download Summary & Checklist

Tips & Tricks

None documented

Jump to:

Basics

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Color and Contrast

Checklist - Deque

Colors that Convey Information

  • Any information conveyed by color MUST be accompanied by a programmatically-discernible text alternative.
  • The text alternative for information conveyed by color MUST accurately convey the same information without color.
  • Any information conveyed by color MUST be accompanied by a visible alternative (text, image, etc.) that does not depend on color for meaning.
  • Color alone MUST NOT be used to distinguish links from surrounding text unless the color contrast between the link and the surrounding text is at least 3:1. An additional differentiation (e.g. underline, outline, etc.) SHOULD BE provided as well.

Contrast

  • Small text (under 18 point regular font or 14 point bold font) MUST have a contrast ratio of at least 4.5 to 1 with the background.
  • Large text and images of large text (at or over 18 point or 14 point bold) MUST have a contrast ratio of at least 3 to 1 with the background.
  • The contrast of UI control boundaries compared to adjacent areas SHOULD be sufficient (3 to 1 for UI control boundaries measuring at least 3px by 3px, and 4.5 to 1 for all other UI controls) to distinguish the UI control from the adjacent areas.
  • Small text (under 18 point regular font or 14 point bold font) SHOULD have a contrast ratio of at least 7 to 1 with the background.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Animations and Motion

Checklist - Deque

Parallax and Accelerometer Animations

  • Moving the physical device SHOULD NOT cause non-essential visual motion or animations (e.g. parallax effects)
  • Users MUST be able to disable any non-essential motion-sensitive visual effects.

Moving or Disappearing Content

  • Automatically moving, blinking, or scrolling content that lasts longer than 5 seconds MUST be able to be paused, stopped, or hidden by the user.

Blinking or Flashing Content

  • A screen MUST NOT contain content that flashes more than 3 times per second unless that flashing content is sufficiently small, the flashes are of low contrast, and do not violate general flash thresholds.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Audio and Video

Checklist - Deque

Captions

  • All prerecorded video MUST have synchronized captions.
  • All live multimedia (video plus audio) events that contain dialog and/or narration MUST be accompanied by synchronized captions.
  • Live audio consisting mainly of dialog and/or narration SHOULD have synchronized captions.

Transcripts

  • All prerecorded video and audio MUST have text transcripts.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Text Content

Checklist - Deque

Language Settings

  • The language of the page MUST be programmatically identified.
  • The language of sections of content that are different from the app's default language MUST be identified in such a way that they can be discovered by assistive technology.

Text Resize

  • The screen MUST be readable and functional when text is set to 200% of its initial size.

Emojis

  • Emojis MAY be used in text content.
  • Custom emojis in custom keyboards MUST have alternative text.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Images

Checklist - Deque

Alternative Text

  • Images that convey information MUST have a descriptive accessibility label that serves the same purpose and presents the same information as the image.
  • Images that are active MUST have an accessibility label that describes the purpose or function of the image.
  • Images that are too complex to be fully described in a short text alternative MUST have their purpose described using an extended text alternative.
  • Images that do not convey content, are decorative, or with content that is already conveyed in the text MUST NOT be given an alternative text equivalent that is exposed to assistive technology.

Text in Images

  • An image MUST NOT include informative text if an equivalent visual presentation of the text can be rendered using real text.

Download Summary & Checklist

Tips & Tricks

None documented

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented