WCAG 2.1 for Native Mobile Apps

WCAG 2.1 Breakdown for Native Mobile Apps

Introduction

Similar to my main WCAG Summary and Breakdown page, I've taken the time to comb through the criteria and pull out applicable guidelines for native mobile apps. Unlike websites, native mobile apps do not have a set of guidelines yet, and developers tend to have to apply what they can based on accessibility API documentation from Apple and Google while also expanding on whatever they can apply when going through a Voluntary Product Accessibility Template, or VPAT. This page is my personal understanding of the applicable criteria and descriptions of how to apply each in a native app context.

Most federal/government contracts and VPATs call for WCAG 2.0 Level AA compliance, yet at this stage companies need to push for 2.1 compliance if they are moving into remediation. If a company wants to be Level AA compliant, that means that they must satisfy all of the Level A and Level AA criteria. Level AAA is understood by the W3C as being practically impossible to achieve, and they are meant for very specific cases, but beig able to conform to as many AAA criteria as possible is a nice to have if not burdensome to the company.

1. Perceivable

Information and user controls must be presented in a way that all users can perceive.

1.1 - Text Alternatives

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

1.1.1 - Non-Text Content - Level A

All images are hidden from accessibility if they are decorative, or they are given accessibility labels /description if they are required to inform the user of context or important information, with the following exceptions:

Controls, input
If non-text content is a control or takes user input, then it has a name that describes its purpose.
Time-based media
If non-text content is time-based media, then text alternatives provide descriptive identification of the non-text media.
Test
If non-text content is part of a test or exercise that would render it invalid if presented as text, then text equivalents would provide descriptive identification of the non-text content.
Sensory
If non-text content is meant to provide a sensory experience, then text equivalents are provided to create descriptive identification of the non-text content.
CAPTCHA
If the non-text content exists as a way to ensure content is being accessed by a human rather than a computer, then the non-text content is described and accessible options are provided to ensure CAPTCHA can be passed via keyboard and screen readers, along with other sensory modalities so any and all users can pass the CAPTCHA.
Decoration, formatting, invisible
If the non-text content is invisible to users, decorative in intent, or otherwise just being used for formatting, then it must be done in a way to hide itself from assistive technologies.
More Info on 1.1.1 Non-Text Content

1.2 - Time-based Media

Provide alternatives for time-based media.

1.2.1 - Audio-only and Video-only prerecorded - Level A

If the app has any audio-only or video-only pre-recorded media that is served to the user, , they must have transcripts. Video-only media can have descriptive transcripts and captioning.

More Info on 1.2.1 Audio Only and Video Only (Prerecorded)

1.2.2 - Captions - Level A

If the app serves audio or video content with audio, captions must be provided unless the audio is built as an alternative for text content and is clearly labeled as such.

More Info on 1.2.2 Captions (Prerecorded)

1.2.3 - Audio description or media alternative (prerecorded) - Level A

If the app serves video to the user, audio descriptions or time-based media alternatives are provided for pre-recorded video content and synchronized media, unless the video is a media alternative for text based content and is clearly labeled as such.

More Info on 1.2.3 Audio Description or Media Alternative (Prerecorded)

1.2.4 - Captions (Live) - Level AA

Captions are provided for all live audio content in synchronized media if it is served to the user within the app.

More Info on 1.2.4 Captions (Live)

1.2.5 - Audio descriptions (prerecorded) - Level AA

Audio description is provided for all prerecorded video content in synchronized media if served to the user through the app.

More Info on 1.2.5 Audio Description (Prerecorded)

1.2.6 - Sign Language (prerecorded) - Level AAA

Sign language interpretation is provided for all audio content in synchronized media if served to the user through the app.

More Info on 1.2.6 Sign Language (Prerecorded)

1.2.7 - Extended audio description (Prerecorded) - Level AAA

Where pauses in the audio track of prerecorded video are insufficient to allow for audio description, extended audio description is provided for all synchronized media. Extended audio description is where the prerecorded content is paused and edited in places where an audio description narrator can give themselves enough time to fully describe the content. Again, this only applies if video media is served to the user through the app.

More Info on 1.2.7 Extended Audio Description (Prerecorded)

1.2.8 - Media alternatives (prerecorded) - Level AAA

Descriptions or alternatives to time-based media are provided for all prerecorded synchronized media and all prerecorded video-only content if they are served to the user through the app. Transcripts, descriptions, captioning files, etc.

More Info on 1.2.8 Media Alternative (Prerecorded)

1.2.9 - Audio-only (Live) - Level AAA

An alternative for time-based media that gives a user equivalent information to live audio content is provided if this content is available to the user in the app. Direct ASL overlays, live transcripts and captioning, etc.

More Info on 1.2.9 Audio Only (Live)

1.3 - Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1 - Info and Relationships - Level A

Information, structure, and relationships can be programmatically determined or are available in text forms. Examples include required input fields being marked with a color but also utilizing the required attribute or text indicator like an asterisk, optional fields being called out in text instructions before users navigate into the text fields, appropriate table header structures used for tabular content, using headings and text formatting to define content and screen structure.

More Info on 1.3.1 Info and Relationships

1.3.2 - Meaningful Sequence - Level A

Present information in a logical and meaningful way to make the golden path for the user streamlined and easy to understand. Break sections of the screens up using heading annotation for text views, keep flows relatively linear without any context shifting, and have progression through the screen make sense both visually and programmatically.

More Info on 1.3.2 Meaningful Sequence

1.3.3 - Sensory Characteristics - Level A

Do not give users instructions or copy that calls out specific sensory characteristics for control or action identification. Do not only use color, shape, screen position, or sound to indicate how to use a control. For example, do not instruct users to "Tap the big blue triangle button on the bottom-left of the screen."

More Info on 1.3.3 Sensory Characteristics

1.3.4 - Orientation - Level AA

The app should be fully functional in either Portrait or Landscape device orientation, unless the specific orientation is essential to the app purpose. Examples of locked orientation experiences that are essential would be displaying a bank check, a piano app, displaying slides, etc.

More Info on 1.3.4 Orientation

1.3.5 - Identify Input Purpose - Level AA

The purpose of any input field collecting data about the user can be programmatically determined. Inputs are labeled clearly and user agents and assistive technology can understand the purpose of the inputs so that they may be understood through screen readers and controlled via speech and autofill functions. Give all controls accessibility labels, values, hints, and roles, and utilize content descriptions.

More Info on 1.3.5 Identify Input Purpose

1.3.6 - Identify Purpose - Level AAA

This criterion isn't applicable to native mobile apps.

More Info on 1.3.6 Identify Purpose

1.4 - Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

1.4.1 - Use of Color - Level A

Color is not used as the only means to convey information, prompting a response, highlighting an action, etc. Examples would be only using a color to indicate an error, using different colors to call out data in a chart or table , or only using color labels on user controls without additional text labeling.

More Info on 1.4.1 Use of Color

1.4.2 - Audio Control - Level A

If any audio plays for more than 3 seconds in an app that is not initiated by the user, controls are present to allow a user to mute/turn off the audio or control the volume independently of the system audio.

More Info on 1.4.2 Audio Control

1.4.3 - Color Contrast (Minimum) - Level AA

Text and images of text are presented to the user with a contrast ratio of at least 4.5:1, except for text and images of text involved with branding/logos, disabled user controls, pure decoration, or large text. Large text and images of text must have a color contrast of at least 3:1. Ensure that all copy, controls, and content in the app functions with Dynamic Type, Bold text, dark mode, and iOS and Android system color contrast options.

More Info on 1.4.3 Color Contrast (Minimum)

1.4.4 - Resize Text - Level AA

Except for images of text and captions, text can be scaled up to 200% without assistive technology without losing context or functionality. Ensure copy and content works when Dynamic Type, Bold text, screen zoom, and other system accessibility text enhancement options are activated.

More Info on 1.4.4 Resize Text

1.4.5 - Images of Text - Level AA

Text is used to convey information instead of images of text except for when the image of text can be customized by the user for their requirements, or if the image of text is essential to the core operation of the feature or app, or is a logo or part of branding. Add content description or accessibility labels to informative images of text, otherwise just hide/remove them from accessibility.

More Info on 1.4.5 Images of Text

1.4.6 - Color Contrast (enhanced) - Level AAA

Text and Images of Text have a contrast ratio of at least 7:1 except for when incidental text is part of an inactive or disabled user control, are pure decoration or invisible, are part of a logo/branding, or are large scale text or images of text, which would then have a contrast ratio of at least 4.5:1.

More Info on 1.4.6 Color Contrast (Enhanced)

1.4.7 - Low or No Background Audio - Level AAA

Any prerecorded audio-only content that contains primarily foreground speech, is not part of an audio RECAPTCHA challenge, is not an earCon or audio logo, and is not musical expression has at least one of the following conditions met:

No Background
audio contains no background sounds.
Turn Off
background sounds can be turned off.
20db
Background sounds are at least 20 decibels lower than the foreground speech, except for sounds that last 1-2 seconds.
More Info on 1.4.7 Low or No Audio

1.4.8 - Visual Presentation - Level AAA

This criterion is largely dependent on the accessibility options of iOS and Android systems. For the visual presentation of blocks of text, controls are provided to adjust the following attributes:

More Info on 1.4.8 Visual Presentation

1.4.9 - Images of Text (No Exception) - Level AAA

Images of text are only used for pure decoration, or where a presentation of text is essential for the images being conveyed. Logos/branding are considered essential.

More Info on 1.4.9 Images of Text (No Exception)

1.4.10 - Reflow - Level AA

Content can be presented without loss of function or context/readability and without two-dimensional scrolling when zoomed in 400%, or 320 CSS pixels wide. Content should reflow into single column layout allowing the user to scroll in only one dimension to read the text fully. Content that requires two dimensions for usage or meaning is the exception, such as diagrams, images, games, charts, presentations, videos, and interfaces that require keeping scrollbars visible while manipulating content. Check how content functions when Dynamic Type, bold text, system zoom, and accessible magnification features are used in the app.

More Info on 1.4.10 Reflow

1.4.11 - Non-Text Contrast - Level AA

Active user interface components or component s not controlled by the app and graphical elements that are required to understand the content except for when the element is essential have a contrast ratio of 3:1 against the adjacent colors.

More Info on Non-1.4.11 Text Contrast

1.4.12 - Text Spacing - Level AA

In experiences that support the following text properties, especially if allowed by iOS and Android systems, no loss of function or readability occurs when the following properties are set:

More Info on 1.4.12 Text Spacing

1.4.13 - Content on Hover or Focus - Level AA

Hovering can be disregarded in this criterion as it is not a method of interaction in touch-screen interfaces/experiences, but as screen readers function with essentially a keyboard cursor, the focus segment of this criterion remains important. When content becomes visible or hidden when receiving or losing screen reader/keyboard focus, the following are true, with the exception of when the presentation is controlled by the system app functions:

Dismissible
A method is available to dismiss the content without changing focus unless new content communicates an input error or does not obscure/block any underlying content.
Hoverable
Hovering is not an action conveyed through touch interfaces, so this exception can be ignored.
Persistent
The new content remains visible until focus trigger is removed, the user dismisses it, or when the new content is no longer relevant.
More Info on 1.4.13 Content On Hover or Focus

2. Operable

User interface components and controls must be operable.

2.1 - Keyboard Accessible

make all functionality available from a keyboard. Native mobile screen readers function with the same concepts as a browser keyboard focus cursor, but not all experiences between a web cursor and a system screen reader cursor will align.

2.1.1 - Keyboard - Level A

All functionality is operable through a keyboard interface without requiring specific timings for individual keystrokes. Path-dependent user input, such as handwriting entry, are exceptions to this criteria. Keyboard functionality allows for multiple assistive tech methods to function with content and interaction. As native mobile users can connect external keyboards to their phones/devices, this criterion still applies to native apps. Switch controls and keyboards will move screen reader cursors around and interact with inputs and user controls and all interface components must work with no difference between touching/using the on-screen keyboards versus using external keyboards while manipulating system accessibility features.

More Info on 2.1.1 Keyboard

2.1.2 - No Keyboard Trap - Level A

Screen reader and switch control cursors must be freely allowed to move through the interface of the app without getting trapped on any elements of the interface. Dynamically updating text views, shifting elements, or just general screen order/layout must not prevent the cursors from freely moving throughout the entire screen. The only exception is when a modal appears, requiring the cursor to be trapped until a user dismisses it.o

More Info on 2.1.2 No Keyboard Trap

2.1.3 - Keyboard (No Exception) - Level AAA

All functionality of the content is operable through a keyboard and no specific timings are required for individual keystrokes. This can be understood as ensuring that all functions throughout the app are accessible and usable via screen reader, switch controls, and external keyboard manipulation.

More Info on 2.1.3 Keyboard (No Exception)

2.1.4 - Character Key Shortcuts - Level A

Native mobile apps will not be built around keyboard mapping as all interaction is done through a touch interface or with system assistive technology.

More Info on 2.1.4 Character Key Shortcuts

2.2 - Enough Time

Providing users enough time to read and interact with content. General guidelines recommend at least 20 seconds in a timed interaction on screen.

2.2.1 - Timing Adjustable - Level A

For each time limit that is set by the content, at least one of the following is true:

Turn Off
The user is allowed to turn off the time limit before encountering it.
Adjust
The user is allowed to adjust the time limit before encountering it over a wide range up to 10x the original limit.
Extend
The user is informed of when time is about to expire and is given a simple control to extend the limit when pressed within 20 seconds of the alert, and time extension can extend up to 10x the original limit.
Real Time Exception
The timing is required as part of a real-time event, such as an auction, and an alternative to the timing event is possible.
Essential Exception
Timing is essential to the content and extending the limit would invalidate the activity.
20-hour exception
The time limit is longer than 20 hours.
More Info on 2.2.1 Timing Adjustable

2.2.2 - Pause, Stop, Hide - Level A

For any moving, blinking, scrolling, or auto-updating information, the user must be given a control to pause, or hide the content if it starts automatically, lasts more than 5 seconds, and is presented in parallel with other content, unless pausing, stopping, or hiding the content invalidates the activity. Auto-updating content must be allowed to be paused, stopped, or hidden by a user control if it starts automatically and is presented in parallel with other content unless the auto-updating content is essential. Having the app abide by the user's Reduce Motion system settings will go a long way in assisting with this criterion.

More Info on 2.2.2 Pause, Stop, Hide

2.2.3 - No Timing - Level AAA

Timing is not an essential part of the functionality or presentation of the content, except for real time events and non-interactive synchronized media.

More Info on 2.2.3 No Timing

2.2.4 - Interruptions - Level AAA

Interruptions can be postponed or suppressed by the user except when the event is an emergency.

More Info on 2.2.4 Interruptions

2.2.5 - Re-Authenticating - Level AAA

When an authenticated event expires, the user can continue without losing their data when re-authenticating. This is at the behest of the features and abilities offered to native iOS and Android apps in terms of how data is managed when apps are sent to the background or minimized.

More Info on 2.2.5 Re-authenticating

2.2.6 - Time Outs - Level AAA

users are warned about periods of user inactivity that would result in data loss, unless the time period of inactivity that triggers the loss is at least 20 hours.

More Info on 2.2.6 Time-Outs

2.3 - Seizures and Physical Reactions

Do not design content in a way that causes seizures or physical reactions.

2.3.1 - 3 Flashes or Below Threshold - Level A

Pages and content do not contain any objects or elements that flash 3 times in 1 second. Honor the user accessibility system settings surrounding reduced motion and animation.

More Info on 2.3.1 Three Flashes or Below

2.3.2 - Three Flashes - Level AAA

Pages do not contain anything that flashes more than 3 times a second.

More Info on 2.3.2 Three Flashes

2.3.3 - Animation from Interactions - Level AAA

Motion and animation triggered by interaction can be disabled unless the animation is essential to the content.

More Info on 2.3.3 Animation from Interactions

2.4 - Navigable

Provide ways to help users navigate, find content, and determine where they are. Information presented in a linear order makes content navigable by screen reader and keyboard users, plus more understandable to users with cognitive impairments.

2.4.1 - Bypass Blocks - Level A

Native mobile apps utilize headings and containers as navigational elements for screen reader users, so content should be broken up into navigable blocks with heading text views to allow for quick navigation over content and to make moving through the golden path faster and more efficient.

More Info on 2.4.1 Bypass Blocks

2.4.2 - Page Title - Level A

While the initial focus of this criterion was on the HTML page title element, it's still important to have every screen of a native mobile app identified when context shifts. Android has page titles and iOS can perform announcements on screen context shifts and changes, so those accessibility API attributes must be used if there isn't already a screen title heading at the top of the screen order.

More Info on 2.4.2 Page Title

2.4.3 - Focus Order - Level A

When a user can navigate a native app sequentially and the sequence of navigation affects the meaning or operation of the content, focusable elements receive focus in a logical order that preserves meaning/operability. Logical progression of focus order helps keyboard and screen reader users create a mental map of the app and the content within it, and the linear progression should make sense and not jump users around the screen.

More Info on 2.4.3 Focus Order

2.4.4 - Link Purpose in Context - Level A

Links and buttons within a native app should be labelled with meaningful and understandable text. "Learn more" or other forms of vague label copy should not be used, ensuring all users are fully informed about where each link they encounter will take them and what each button will do when tapped.

More Info on 2.4.4 Link Purpose

2.4.5 - Multiple Ways - Level AA

This criterion does not directly apply to native mobile apps as most content and features are self-contained within their own screens, tabs, and views.

More Info on 2.4.5 Multiple Ways

2.4.6 - Headings and Labels - Level AA

Headings and labels describe topic or purpose of the content. Provide descriptive headings and labels and make sure they are programmatically determined

More Info on 2.4.6 Headings and Labels

2.4.7 - Focus Visible - Level AA

The screen reader and accessibility cursor cannot be suppressed in native mobile systems, so this criterion is not applicable to native mobile apps.

More Info on 2.4.7 Focus Visible

2.4.8 - Location - Level AAA

This can be satisfied in a multi-page app by ensuring the view tabs indicate which one is currently selected or active, but in general this criterion may not apply to a native mobile app as information and functions are contained within single-screen views.

More Info on 2.4.8 Location

2.4.9 - Link Purpose (Link Only) - Level AAA

Users are able to understand the purpose of a link through the text alone. Links need to be understood when focused out of context, such as when using a screen reader to jump through every link on a screen. This ensures users are informed as to whether or not they want to navigate to the linked content.

More Info on 2.4.9 Link Purpose (Link Only)

2.4.10 - Section Headings - Level AAA

Section headings are used to organize the content of a screen. If a native app screen or feature flow can be broken up with structured headings, it helps users navigate through long pieces of information and retain more of that information through the structure. Providing heading text views at the beginning of each section of content will satisfy this criteria if it is able to be done.

More Info on 2.4.10 Section Headings

2.4.11 - Focus Visible (Enhanced) - Level AA

Visible focus indicators are controlled by the mobile operating system, but color contrast and shading/subtle animation can be used to boost the overall attention given to the currently focused input.

More Info on 2.4.11 Focus Visible (Enhanced)

2.5 Pointer Accessible

All functionality should be accessible via pointer input devices, for example, via a finger interacting with a touch screen or an electronic pencil/stylus.

2.5.1 - Pointer Gestures - Level A

All functionality that uses multipoint or path based gestures for operation can also be operated with a single pointer. without a path based gesture, unless the multipoint or path gesture is essential. This only applies to native app features that interprets pointer actions and does not apply to actions used by assistive technology. Do not remap system gestures or attempt to bypass assistive technology gestures.

More Info on 2.5.1 Pointer Gestures

2.5.2 - Pointer Cancellation - Level A

For functionality that can be operated with a single pointer, at least one of the following is true:

No down event
The down event does not execute any part of the function.
Abort/Undo
Completion of the function is on the up event and a mechanism is provided to abort the function before completion or undo the function after completion.
Up Reversal
The Up Event reverses any outcome of the preceding Down Event.
Essential
Completing the function on the down event is essential.

This criteria only applies to native app features that interprets pointer actions and not to gestures used with assistive technology.

More Info on 2.5.2 Pointer Cancellation

2.5.3 - Label and Name - Level A

User interface components with labels comprised of text or images of text name contains the text that is represented visually. The name must match the label or the text that appears visually, so a user using voice commands can clearly say which control they'd like to activate to navigate to, and to eliminate any confusion when attempting to understand a control or interact with it using a screen reader. Ensuring user controls have accessibility labels or that they are grouped with their corresponding text view labels is required for this criterion.

More Info on 2.5.3 Label and Name

2.5.4 - Motion Actuation - Level A

Functionality that can be operated by device or user motion can also be operated by user input controls. Response to the motion activation can be disabled to prevent accidental actuation, unless:

Supported Interface
The motions used to operate functionality are through an accessibility supported interface.
Essential
The motion is essential for the function and disabling it would invalidate the activity.
More Info on 2.5.4 Motion Actuation

2.5.5 - Target Size - Level AAA

Target size for pointer inputs should be at minimum 44px by 44px except when:

Equivalent
The target is available through an equivalent link or control on the same screen that is at least 44px by 44px.
In-line
The target is in a sentence or a block of text.
user Agent Control
The size of the control is determined by the operating system and not by us.
Essential
A particular presentation of the target is essential to the information being conveyed.
More Info on 2.5.5 Target Size

2.5.6 - Concurrent Input Mechanisms - Level AAA

Users should be able to switch input mechanisms at any point should the user determine that certain tasks and interactions are more easily accomplished by using an alternative input mechanism. Content must not limit the user's interaction to any particular input mechanism unless the restriction is essential, or is required to ensure the security of the content or to respect user settings.

More Info on 2.5.6 Concurrent Input Mechanisms

2.5.7 - Dragging - Level AA

Any functionality that uses a dragging movement can also be performed with a single pointer without a dragging gesture, unless the act of dragging is essential to the functionality. This only applies to native app features that interprets pointer actions, not to functionality used to operate assistive technology.

More Info on 2.5.7 Dragging

3. Understandable

Information and the operation of user interface must be understandable.

3.1 - Readable

Make content readable and understandable.

3.1.1 - Language of Page - Level A

The language of an app can be programmatically determined. Make sure the app is localized and that the appropriate language is set by the system settings or from the user settings.

More Info on 3.1.1 Language of Page

3.1.2 - Language of Parts - Level AA

Text that is presented in another language different from the main language of the app is also set correctly using correct language annotation for the native operating system and the copy or control attributes. Proper names, technical terms, words of an indeterminate language, or and words or phrases that are part of the vernacular of immediately surrounding text are excluded from this criteria.

More Info on 3.1.2 Language of Parts

3.1.3 - Unusual Words - Level AAA

A mechanism is available for users to learn about and understand text used in an unusual or restricted way, such as idioms and jargon. Linking the first instance of the word or phrase to a description list or glossary satisfies this criteria, or providing inline explanations, and providing an online dictionary to aid in understanding.

More Info on 3.1.3 Unusual Words

3.1.4 - Abbreviations - Level AAA

There is a way for users to understand the definitions or expansions of abbreviations when they appear in native mobile app copy.

More Info on 3.1.4 Abbreviations

3.1.5 - Reading Level - Level AAA

If text content becomes more advanced than a lower secondary education level, excluding proper names and titles, supplemental content or a version that has the content rewritten in a lower secondary education level is available.

More Info on 3.1.5 Reading Level

3.1.6 - Pronunciation - Level AAA

Users have a way of learning the pronunciation of words when the words are ambiguous in the context and pronunciation is not known. Providing a text glossary with pronunciation techniques, audio files to hear the pronunciation, and allowing diacritical marks to be toggled on and off are some techniques for satisfying this criteria.

More Info on 3.1.6 Pronunciations

3.2 - Predictable

Make apps appear and operate in predictable ways.

3.2.1 - On Focus - Level A

When an object in an app receives focus, it does not initiate a change of context. Functionality should be predictable, and jumping a user around through content or context automatically after they have focused on an element breaks this predictability.

More Info on 3.2.1 On Focus

3.2.2 - On Input - Level A

When a user changes the value or enters information into an input, context must not automatically change unless the user has been informed of the context change before they interact with the component.

More Info on 3.2.2 On Input

3.2.3 - Consistent Navigation - Level AA

Navigational elements must appear in consistent locations and patterns throughout the app. Back buttons, navigational tab bars and panels, all must be consistently labelled and appear within the same area of the screen order. Users are not able to change or adjust the presentation or location of the native controls like they are sometimes able to tweak on websites, so consistency is key for a usable and accessible flow through an app.

More Info on 3.2.3 Consistent Navigation

3.2.4 - Consistent Identification - Level AA

Components that have the same functionality throughout a set of screens are identified consistently and do not change context or name. Consistent labeling helps users understand the content and operate the app easier and reduces cognitive load.

More Info on 3.2.4 Consistent Identification

3.2.5 - Change on Request - Level AAA

Changes of context are initiated only when the user requests them or a mechanism is available for a user to turn off these changes. Automatic context changes cause confusion for all assistive tech users and creates unpredictability across the entire app, so users must be able to control context changes.

More Info on 3.2.5 Change on Request

3.3 - Input Assistance

Help users avoid and correct mistakes.

3.3.1 - Error Identification - Level A

If an input error is automatically detected, the error is identified and described to the user in text. Usually presented as text underneath the input and spoken by the screen reader.

More Info on 3.3.1 Error Identification

3.3.2 - Labels and Instructions - Level A

Labels or instructions are provided when content requires user input.

More Info on 3.3.2 Labels or Instructions

3.3.3 - Error Suggestion - Level AA

If an input error is automatically detected, and suggestions for correction are known, then those suggestions are provided to the user unless it would jeopardize the security or purpose of the content. Provide text descriptions about the fields or inputs with the error, and make sure to indicate which inputs are required in the user flow.

More Info on 3.3.3 Error Suggestion

3.3.4 - Error Prevention (Legal, Financial, Data) - Level AA

For any apps that have users making legal commitments, modify or deal with user financial data, edit user inputted data or databases, one of the following must be true:

Reversible
Submissions are reversible.
Checked
User input is checked for errors and users have the opportunity to correct them.
Confirm
A mechanism is provided to allow users to review, edit, and confirm their input before submission.

Users must be given the opportunity to avoid errors that may result in serious consequences, such as ordering non-refundable tickets, anything that causes serious legal or financial hardship, or causing massive loss of user data within a database.

More Info on Error Prevention (Legal, Financial, Data)

3.3.5 - Help - Level AAA

Context sensitive help is available. This allows users with disabilities to not make mistakes while also not losing their place in the context of the content they are interacting with, or allows them to quickly learn how to interact within content without losing their place.

More Info on 3.3.5 Help

3.3.6 - Error Prevention (All) - Level AAA

For apps that require the user to input and submit information, one of the following is true:

Reversible
Submissions are reversible.
Checked
User input is checked for errors and users have the opportunity to correct them.
Confirm
A mechanism is provided to allow users to review, edit, and confirm their input before submission.
More Info on 3.3.6 Error Prevention (All)

4. Robust

Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies.

4.1 - Compatibility

Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1 - Parsing - Level A

Use correct code parsing for SwiftUI, Java, or whichever library is being used to generate a native mobile app. Use correct implementations of native controls and follow the accessibility API documentation provided by Apple and Google to the letter.

More Info on 4.1.1 Parsing

4.1.2 - Name, Role, Value - Level A

For all interactive user components, roles can be programmatically determined, states, properties and values that can be set by the user can be programmatically set, and notifications of changes to these components are made available to the user agent. Assistive technologies will be able to announce value changes and properly identify the role and state of components to users. Buttons, links, headings, input controls are appropriately identified. Collapsed, expanded, and selected states, value amounts, etc. are identified.

More Info on Name, Role, Value

4.1.3 - Status Messages - Level AA

In native mobile apps, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. This is a guideline to implement toasts, accessibility announcements, and status announcements when a user completes a task. Examples:

Search button
User hits a Search button and screen reader announces "5 search results returned" without user having to navigate to the status message.
Cart
Adding items to a cart would automatically have a screen reader announce and update the cart item total, allowing user to know that they've successfully added items to the cart without having to navigate to the Cart icon/button to hear the amount.
Progress/Busy
When a process is enabled that puts up a Loading or Busy throbber or graphic, the screen reader automatically announces the role of the alert or announces progress bar status.
Form Submission
After user submits a form, text appears that states "Form Successfully submitted" and the screen reader announces this automatically.
Errors
After incorrect form submission, text appears explaining that there are 4 errors on the page, and the screen reader announces this.

Ultimately, this will apply to any and all status messages that appear as text on the screen during user interaction. Utilize the tools provided by Apple and Google through their accessibility APIs to properly inform users of the results of their actions as needed.

More Info on 4.1.3 Status Messages

Resources