\n Introduction\n
\n iOS Assistive Technologies\n
- \n Low Effort—High Reward\n
  - \n Low Effort\n
  - \n High Reward\n
  \n
\n
\n Creativity\n
\n Guidelines\n
- \n Summary\n
- \n Principles\n
- \n 1. Perceivable\n
  - \n 1.1 Text Alternatives\n
  - \n 1.2 Time-based Media\n
  \n
\n
\n Conformance\n
- \n Accessibility Semantics Audit\n
\n
\n Technical Reference\n
- \n Intro\n
- \n Table of Contents\n
\n

Introduction

Thank you for showing an interest in making your product available to all users, regardless of their disabilities.

\n\n

The 2011 WHO World Report on Disability estimates more than 15 percent (1 Billion) of the world’s population (7 Billion) live with some kind of disability. Contrary to common perception, not all disabilities are severe (e.g. blindness, paraplegia, etc).

\n\n

The 2010 WHO Global Data on Visual Impairments estimates that an average 30 percent of the population in developed countries suffer from some kind of visual impairment. This includes even light Astigmatism (short/long-sightedness), which in combination with low text contrast may cause uncomfortable headaches.

\n\n

Insufficient text contrast, bad ergonomics, or high cognitive load impact everyone, it’s just that people with severe impairments feel it most, as for them, these issues don’t just slow them down, they stop them from achieving their goals.

\n\n

Everyone can experience External Impairments, they introduce or aggravate existing impairments.

\n\n

Examples of External Impairments include:

\n\n

Bright sunlight may impair color contrast, resulting in temporary color blindness and sight reduction;
Driving or even walking impair cognitive and motor abilities, resulting in a temporary learning or physical impairment;
Noisy environments impair hearing, resulting in temporary hearing loss;
Flashing lights impair vision, causing distraction or epileptic seizures.

\n\n

Accessibility adds robustness, improving experience for both temporarily and permanently impaired users.

\n\n

\n
“Disability need not be an obstacle to success.”, (Professor Stephen W. Hawking, 2011 World Report on Disability)
\n

\n\n

Stephen Hawking is proof that given the right conditions and Assistive Technology, even severe disabilities pose no barrier to living a happy, successful life.

\n\n

I’ve put myself in the shoes of someone who relies on Assistive Technology, it didn’t take long to encounter a barrier I could not surpass.

\n\n

We have the moral duty to remove the barriers to participation, to invest time and effort into making tools appropriately accessible to everyone, unlocking their full potential.

\n\n

\n
“Unfortunately, unseen customers are considered nonexistent.”
\n

\n\n

The UN Factsheet on Persons with Disabilities estimates that 75% of the FTSE 100 companies in the UK do not meet basic levels of accessibility, thus missing out on more than £96 ($147) million in revenue. Unfortunately, unseen customers are considered nonexistent.

\n\n

If not for moral values, do it for financial values, either way everyone benefits.

\n\n

iOS Assistive Technologies

iOS provides free, built-in Assistive Technologies to make apps and websites accessible for people with impairments in the following groups: Vision; Hearing; Physical and Motor Skills; Learning and Literacy.

\n\n

The most popular Assistive Technology is VoiceOver. It enables understanding of, and interaction with on-screen content for vision-impaired users — here’s how to enable VoiceOver and give it a try.

\n\n

Input and Output peripherals (e.g. Switches and Braille Displays respectively), are automatically handled by iOS.

\n\n

For detailed information, visit Apple’s Accessibility Website.

\n\n

Low Effort—High Reward

iOS Accessibility has been designed to be Low Effort—High Reward.

\n\n

Low Effort

\n\n

By design, iOS apps have enough Accessibility Semantics to be 80% accessible. Reaching 90% is easy (mostly labeling elements), and 100% is usually trivial, even for custom elements and gestures.

\n\n\n\n

High Reward

\n\n

Basic Accessibility Semantics enable a wide variety of aids, from Visual (e.g. VoiceOver) to Physical and Motor (e.g. Switch Control). Accessibility Semantics are also the cornerstone of development best practices such as Automated Testing, making Accessibility Conformance a by-product of a robust application.

\n\n

Creativity

Accessibility on iOS does not limit design possibilities or control over the final interface.

\n\n

Custom elements and interactions can painlessly be made as accessible as built-in Buttons/Labels/etc (more on that later).

\n\n

While users control the status of features such as Invert Colors ¹ or Mono Audio ², app creators can and should³ define how their app behaves when Assistive Technologies are enabled (see documentation and examples for: Accessibility Accommodations, and other Technical Reference topics).

\n\n

Invert Colors: inverting screen colors helps people who are sensitive to brightness, color blind, or have low vision.↩\n
Mono Audio: Stereo audio sometimes contains distinct tracks for each ear. When using headphones, people who are deaf or hard to hear on one ear would miss the audio track for the impaired ear. Mono Audio delivers both tracks to the non-impaired ear so that no information is lost.↩\n
Assistive Technologies such as “Reduced Motion“ or “Reduced Transparency” help people with certain impairments, it is recommended to tone down animations and transparency when these settings have been enabled by the user.↩\n

\n\n\n

Guidelines

\n\n

Summary

\n
“There was no such document for iOS.”
\n

\n\n

For the Web, WCAG (Web Content Accessibility Guidelines) is the industry-standard accessibility reference.

\n\n

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.

\n\n

There’s no such document for iOS.

\n\n

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).

\n\n

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.

\n\n

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.

\n\n

The WCAG Accessibility Conformance Levels have been kept, supporting all Single-A Guidelines is required for claiming your app is accessible.

\n\n

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).

\n\n

The Accessibility Conformance chapter provides more information on this topic.

\n\n

Principles

\n\n

Perceivable
Operable
Understandable
Robust

\n\n

1. Perceivable

\n
“Information can’t be invisible to all of their senses.”
\n

\n\n

1.1 Text Alternatives

Provide text alternatives for any non-text content.

\n\n

1.1.1 Non-text Content (Level A)

\n\n

Guideline

Describe non-text content using Accessibility Semantics so Assistive Technologies can help users perceive (and interact with) content.

\n\n

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.

\n\n

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.

\n\n

Examples of non-text content include: Image, Video, Audio, etc; controls such as Sliders, Buttons, Switches, etc; CAPTCHAS, Decoration, Visual Formatting, and Invisible Elements.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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”.

\n\n

1.2 Time-based Media

Provide alternatives for time-based media.

\n\n

1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

\n\n

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.

\n\n

Understanding

Audio-only, video-only, or any content form presented over time, require Hearing, Vision, or Learning abilities that users may not possess.

\n\n

Assistive Technologies allow users to select alternatives that convey equivalent information through other senses, at a more comfortable pace, or through reading aids.

\n\n

Solving

Provide Audio Descriptions for the Vision-impaired, Closed Captions for Hearing-impaired, and Transcripts for Learning or Vision & Hearing-impaired.

\n\n

Refer to Apple’s HTTP Live Streaming Documentation for more information, and the HTTP Live Streaming overview for HLS streaming examples and more resources.

\n\n

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.

\n\n

Example #2: An application containing prerecorded audio-only media (e.g. Podcasts), should provide a text representation (i.e. transcript).

\n\n

1.2.2 Captions (Prerecorded) (Level A)

\n\n

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.

\n\n

Understanding

Audio media requires Hearing, or Learning abilities that users may not possess.

\n\n

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.

\n\n

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.

\n\n

Examples

Example #1: An app serving prerecorded audio content (e.g. Podcast) which includes Closed Captions for the selected media.

\n\n

Example #2: An app serving prerecorded Video content synchronized with an Audio track (e.g. Netflix), which includes Closed Captions or the selected media.

\n\n

1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

\n\n

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.

\n\n

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.

\n\n

Solving

Provide Audio Descriptions for the Vision-impaired, Closed Captions for Hearing-impaired, and Transcripts for Learning or Vision & Hearing-impaired.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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”).

\n\n

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.

\n\n

Conformance

For the purpose of Accessibility Conformance, Web Accessibility Guidelines 2.0 (WCAG 2.0) have been adopted or adapted by the vast majority of governments, including Europe, Australia, New Zealand, or Israel.

\n\n

In the United States, Section 508 of the Rehabilitation Act of 1973, a subset of WCAG 2.0, is used as the official legislation.

\n\n

Accessibility Conformance makes business sense, as it increases your user base, and is mandatory for products used by Government entities, NGOs, Education, and industries such as Travel. This will change depending on country, and have in mind lawsuits against inaccessible products are frequent.

\n\n

The guidelines included in this book are based on WCAG 2.0, while references to web and desktop have been replaced with their iOS equivalents, the original goals have been respected to ensure Accessibility Conformance.

\n\n

Accessibility Conformance validation is a manual process as there are currently no automated tools for this purpose.

\n\n

To aid you with Accessibility Conformance validation I’ve included in this book a section titled “Accessibility Semantics Audit” (ASA).

\n\n

Additionally, if you’re targeting the US market, the Voluntary Product Accessibility Template® (VPAT®) will help you document your product’s conformance with Section 508. Within VPAT, the section you’re looking is “Section 1194.21 Software Applications and Operating Systems”.

\n\n

IMPORTANT: No tool or process will provide a complete guarantee your product is Accessible to everyone, even if it conforms to all Accessibility Guidelines, due to the unpredictable nature of impairments, users may still encounter challenges when using your product. Conversely, a product that does not comply to some Accessibility Guidelines may still be Accessible as the supported guidelines may account for all the needs of a specific user.

\n\n

Accessibility Semantics Audit

\n\n

The Accessibility Semantics Audit (ASA) helps quickly determine a basic level of Accessibility Conformance, below Single-A, for individual user interface elements.

\n\n

While Single-A is required to conform with Government legislation, ASA-level conformance still provides significant value at a very low cost.

\n\n

The value of ASA lies in the effort to reward ratio. First, the simple querying of every user interface element with 6 straightforward questions (e.g. Where am I?), results in a preliminary Accessibility Compliance status.

\n\n

Second, applications created with built-in user interface components leave few questions unanswered, filling in the gaps is not only easy, but also goes a long way to meeting many of the Accessibility Guidelines which only require the presence of Accessibility Semantics, and facilitates Automated Testing.

\n\n

The following is a list of questions, along with their description and answer information.

\n\n

Technical Reference

\n\n

Intro

This section includes main and less known accessibility-related methods, constants, notifications and helper functions from the iOS SDK (9.0).

\n\n

This documentation has been made easier to understand by reducing the amount of abstraction, jargon, verbosity, while still including declaration information, usage tips and examples.

\n\n

Main takeaways:

\n\n

All UIViews conform to the UIAccessibility protocol
Built-in iOS technologies do most of the work for you
Accessibility APIs provide granular control, down to speech language, pitch, and interpretation.

\n\n\n\n

\n\n

\nUIAccessibility\n
\n
\nUIAccessibilityContainer\n
\n
\nUIAccessibilityElement\n
- accessibilityContainer
\n
\nUIAccessibilityAction\n
\n
UIAccessibilityCustomAction
\nAccessibility Accommodations\n
\n
\nAssistive Technology State\n
- .IsGuidedAccessEnabled
- .IsSpeakScreenEnabled
- .IsSpeakSelectionEnabled
- .IsSwitchControlRunning
- .IsVoiceOverRunning
\n
\nAccessibility Notifications\n
\n
\nControl Events\n
- .AllEvents
- .AllTouchEvents
- .AllEditingEvents
- .EditingDidBegin
- .EditingChanged
- .EditingDidEnd
- .EditingDidEndOnExit
- .PrimaryActionTriggered
- .TouchDown
- .TouchDownRepeat
- .TouchDragInside
- .TouchDragOutside
- .TouchDragEnter
- .TouchDragExit
- .TouchUpInside
- .TouchUpOutside
- .TouchCancel
- .ValueChanged
\n
\nCustomizing Speech\n
- .Pitch
- .Punctuation
- .Language
\n
\nHelpers\n
\n

\n\n\n

\n\n","tocStructure",[160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176],{"_76":77,"_43":78,"_70":-5,"_79":80,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":77,"_43":86,"_70":-5,"_79":87,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":91,"_70":-5,"_79":92,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":96,"_43":97,"_70":-5,"_79":98,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":96,"_43":100,"_70":-5,"_79":101,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":77,"_43":103,"_70":-5,"_79":104,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":77,"_43":107,"_70":-5,"_79":108,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":111,"_70":-5,"_79":112,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":114,"_70":-5,"_79":115,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":117,"_70":-5,"_79":118,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":96,"_43":120,"_70":-5,"_79":121,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":96,"_43":123,"_70":-5,"_79":124,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":77,"_43":126,"_70":-5,"_79":127,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":130,"_70":-5,"_79":131,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":77,"_43":133,"_70":-5,"_79":134,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":137,"_70":-5,"_79":138,"_72":81,"_93":-5,"_94":-5,"_84":-5},{"_76":90,"_43":140,"_70":-5,"_79":141,"_72":81,"_93":-5,"_94":-5,"_84":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Table of Contents

Introduction

iOS Assistive Technologies

Low Effort—High Reward

Low Effort

High Reward

Creativity

Guidelines

Summary

Principles

1. Perceivable

1.1 Text Alternatives

1.1.1 Non-text Content (Level A)

Guideline

Understanding

Solving

Examples

1.2 Time-based Media

1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

Guideline

Understanding

Solving

Examples

1.2.2 Captions (Prerecorded) (Level A)

Guideline

Understanding

Solving

Examples

1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

Guideline

Understanding

Solving

Examples

Conformance

Accessibility Semantics Audit

Technical Reference

Intro

Table of Contents