Guidelines
Summary
“There was no such document for iOS.”
For the Web, WCAG (Web Content Accessibility Guidelines) is the industry-standard accessibility reference.
WCAG results from the effort of more than 100 accessibility professionals over multiple years, offering solid recommendations, straightforward guideline classification ranging from Single-A (essential) to Triple-A (ideal), and is the adopted legislation by most governments around the world.
There’s no such document for iOS.
Apple offers the best and cheapest (free) assistive technologies, but documentation is either purely technical (#1), in hour-long video form (#2, #3), or consumer-oriented (#4).
This book aims to fill that gap, the guidelines here outlined provide an actionable and easy-to-understand reference for designers, developers or anyone wanting to understand more about iOS Accessibility.
The four main WCAG principles have been kept (listed below), while references to technologies (e.g. HTML, User-Agent) or input methods (e.g. Keyboard, Mouse) have been removed/replaced with iOS equivalents to ensure validity and familiarity.
The WCAG Accessibility Conformance Levels have been kept, supporting all Single-A Guidelines is required for claiming your app is accessible.
It is understood that fully satisfying higher conformance levels (Double/Triple-A) may not always be possible due to the nature of certain apps (i.e. a drawing app cannot be made fully keyboard-accessible, or a live-streaming app cannot offer accurate real-time captions).
The Accessibility Conformance chapter provides more information on this topic.
Principles
- Perceivable
- Operable
- Understandable
- Robust
1. Perceivable
“Information can’t be invisible to all of their senses.”
1.1 Text Alternatives
Provide text alternatives for any non-text content.
1.1.1 Non-text Content (Level A)
Guideline
Describe non-text content using Accessibility Semantics so Assistive Technologies can help users perceive (and interact with) content.
Understanding
Assistive Technologies inform and help users interact with your app. For this to happen, your app must be described to Assistive Technologies through Accessibility Semantics.
By understanding your app, Assistive Technologies provide features that allow users to skim content without even seeing the screen, navigate by tilting their heads, reading and writing with a Braille keyboard, and much more without developer having explicitly add support for these and future features.
Examples of non-text content include: Image, Video, Audio, etc; controls such as Sliders, Buttons, Switches, etc; CAPTCHAS, Decoration, Visual Formatting, and Invisible Elements.
Text is an elementary Accessibility Semantic, assigned to elements using an Accessibility Label, it helps the Visual-impaired to at least perceive screen contents through Text-to-Speech.
Solving
Consider and plan how non-text content will be described to users (e.g. Speech) and understood by Assistive Technologies. All non-text content should be described using one or more of the following Accessibility Semantics: Label, Traits, Hint, Value, and Visibility.
Examples
Example #1: An application where the description for a Video element fails to convey its nature or metadata such as duration, is seen as a failure to meet this guideline.
Example #2: An application, such as iOS Photos, where the description for a Video element successfully conveys the element’s nature (Video), metadata useful for element distinction (e.g. duration, creation time), and appropriate Accessibility Semantics such as a Trait identifying the element as interactive (e.g. Button), and a Hint informing the video will be played back upon button activation (double-tapping it). In simpler terms, this application displays videos as buttons with a thumbnail for background, sets their Label to the video’s duration and creation date, and Hint with a simple string such as “double-tap to play”.
1.2 Time-based Media
Provide alternatives for time-based media.
1.2.1 Audio-only and Video-only (Prerecorded) (Level A)
Guideline
Provide text alternatives containing equivalent information to original prerecorded audio-only and video-only media, so users can still perceive content despite their impairments.
Understanding
Audio-only, video-only, or any content form presented over time, require Hearing, Vision, or Learning abilities that users may not possess.
Assistive Technologies allow users to select alternatives that convey equivalent information through other senses, at a more comfortable pace, or through reading aids.
Solving
Provide Audio Descriptions for the Vision-impaired, Closed Captions for Hearing-impaired, and Transcripts for Learning or Vision & Hearing-impaired.
Refer to Apple’s HTTP Live Streaming Documentation for more information, and the HTTP Live Streaming overview for HLS streaming examples and more resources.
Examples
Example #1: An application, where a series of steps are demonstrated in prerecorded video-only media, should provide an audio or text representation of the same content.
Example #2: An application containing prerecorded audio-only media (e.g. Podcasts), should provide a text representation (i.e. transcript).
1.2.2 Captions (Prerecorded) (Level A)
Guideline
Provide Closed Captions for all prerecorded Audio-only, or Audio media synchronized with other formats such as Video, or time-based interactive components. Unless the media is clearly labeled as an alternative for existing text content.
Understanding
Audio media requires Hearing, or Learning abilities that users may not possess.
Solving
Provide Closed Captions so users can perceive content despite their impairments. Alternatively, solutions to Guideline 1.2.3, namely Transcripts, will also ensure content can be perceived despite Hearing or Learning impairments.
Refer to Apple’s HTTP Live Streaming Documentation for more information, and the HTTP Live Streaming overview (HLS) for HLS streaming examples and more resources.
Examples
Example #1: An app serving prerecorded audio content (e.g. Podcast) which includes Closed Captions for the selected media.
Example #2: An app serving prerecorded Video content synchronized with an Audio track (e.g. Netflix), which includes Closed Captions or the selected media.
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)
Guideline
Provide an audio Description of prerecorded video-only media, an alternative for video-synchronized media (i.e. video + audio) or time-based interactive components (i.e. animation). Unless the media is already a text alternative.
Understanding
Video-only, or any content form presented over time (i.e. animated elements), can only be perceived if Vision is available, or if an individual’s Learning & Literacy abilities are sufficient to keep up with the rate of information.
Solving
Provide Audio Descriptions for the Vision-impaired, Closed Captions for Hearing-impaired, and Transcripts for Learning or Vision & Hearing-impaired.
Refer to Apple’s HTTP Live Streaming Documentation for more information on how to add audio and video alternatives to media, and the HTTP Live Streaming overview (HLS) for HLS streaming examples and more resources.
No work is necessary if the same information is already conveyed through text, as this provides the use with at least one way to access the information.
Examples
Example #1: An application where the evolution of a cell over a period of time is represented exclusively as video, should also provide an audio description for Vision-impaired users.
Example #2: An application such as Netflix containing prerecorded video media (I.e. Movies, Series, Documentaries), where in addition to Closed Captions, an alternative Audio Description track containing not only the original audio, but additional voiceover describing information contained in the video (e.g. “a woman sits by the window”).
Example #3: An educational app containing an interactive animation of a working engine, should also convey the lifecycle through text, which not only can be consumed by Vision-impaired users, but at a pace that’s comfortable to the user.