WCAG 2.2 Breakdown for Native Mobile Apps
Last Page Update: Aug 28, 2024
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.2 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 being 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.
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.
Again, don't use system controls just for their visual style, but only for their semantic purpose. Tables do not have parity between iOS and Android, but building a native table should attempt to include as much functionality as a web view table, if not just deferring to using a web view. Headings must be used to break apart sections of content. Lists also do not have parity across iOS and Android; enumerations have to be provided in the text of a list in iOS, or contains the bullet marker within the strings making up each list item. Lists are native in Android and should be marked up as such. Key/Value pairings need to be grouped together into single swipe stops/focus targets.
More Info on 1.3.1 Info and Relationships1.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 Sequence1.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 Characteristics1.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 Orientation1.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 Purpose1.3.6 - Identify Purpose - Level AAA
This criterion isn't applicable to native mobile apps.
More Info on 1.3.6 Identify Purpose1.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 Color1.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 Control1.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 Text1.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 Text1.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.
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:
- Foreground and background colors can be changed.
- Width is no more than 80 characters.
- Text is not center justified, aligned to both the left and right margins.
- Line Spacing/leading is at least 1.5 spaces within paragraphs, and paragraph spacing is at least 1.5x larger than line spacing.
- Text can be resized up to 200% and reflow so a user does not have to scroll horizontally to read all of the content.
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 Reflow1.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 Contrast1.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:
- Line Height/Line Spacing set to at least 1.5x font size.
- Spacing paragraphs to at least 2x the font size.
- Letter Spacing/Tracking set to at least 0.12x the font size.
- Word Spacing set to at least 0.16x the font size.
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.
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 Keyboard2.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 Trap2.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 Shortcuts2.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.
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, Hide2.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 Timing2.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 Interruptions2.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-authenticating2.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-Outs2.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 Below2.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 Flashes2.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 Interactions2.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 Blocks2.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 Title2.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 Order2.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 Purpose2.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 Ways2.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 Labels2.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 Visible2.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 Location2.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 Headings2.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.4.12 - Focus Appearance (Enhanced) - Level AAA
As focus indicators for VoiceOver and TalkBack are controlled by the device operating systems, this criterion is not applicable to native mobile apps. Android systems using TalkBack give users the ability to alter the color and appearance of the focus indicator, but VoiceOver locks the appearance of it's focus indicator.
More Info on 2.4.12 Focus Appearance (Enhanced)2.4.13 - Page Break Navigation - Level A
This criterion is not applicable for native mobile apps.
More Info on 2.4.13 - Page Break Navigation2.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 Gestures2.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 Cancellation2.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 Name2.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.
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.
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 Mechanisms2.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 Dragging2.5.8 - Target Size (Minimum) - Level AA
Targets are at least 24px by 24px, unless:
- Spacing - the target offset to adjacent targets is at least 24px.
- The target is inline in a block of text or sentence.
- Essential - the particular presentation of the target is essential to what is being conveyed.
Note that this criterion doesn't specify that the visible pixels of controls have to have the 24px width and height minimum, just that a 24px diameter circle around the control encompasses the touch target area. Since thumbs are at least 70px wide, strongly recommend incorporating that measurement into the overall touch target sizing of native app controls.
More Info on 2.5.8 - Target Size (Minimum)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 Page3.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 Parts3.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 Words3.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 Abbreviations3.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 Level3.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 Pronunciations3.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 Focus3.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 Input3.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 Navigation3.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 Identification3.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 Request3.2.6 - Consistent Help - Level A
On any screen in a set of native app screens that provide the following kinds of help, access to at least 1 form of finding help exists in the same relative order on each screen. This criteria does not require that any of these methods are to be present on a native app screen, but only dictates that if Help is offered that it be put in a consistent place across all screens in the app.
- Human Contact details
- phone number, email address, hours of operation
- Human contact mechanism
- chat, social media, messaging system, contact form
- Self-help option
- FAQs, How Do I? page, etc.
- Fully automated help mechanism
- Chat bot, AI, etc.
Putting Help options in a clear and consistent place on every screen makes it much easier and more usable for users to find them.
. More Info on 3.2.6 - Consistent Help3.2.7 - Visible Controls - Level AA
Native mobile apps do not have a hover state, and helper text can be applied to the accessibility labels of controls to speak visible usage hints when controls are focused. This criterion isn't applicable to native apps.
More Info about 3.2.7 - Visible Controls3.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 Identification3.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 Instructions3.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 Suggestion3.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 Help3.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.
3.3.7 - Accessible Authentication Level A
For any kind of user authentication that has a cognitive function test, such as remembering a username/password, transcription/typing in characters, Use of correct spelling, Performance of calculations, or solving puzzles, an alternate method that does not require a cognitive function test is available for the user, or a mechanism is built in that assists the user through the test. Those mechanisms can be allowing function with password manager systems to help with the memorization test, and support of copy and paste to help with a transcription test.
Success examples:
- Use properly marked up Username, Email, and password fields so that native apps can autocomplete/autofill from password managers.
- The native app authentication does not block copy/paste functionality in the text/input fields.
- The native app uses alternative user authentication methods such as webAuthn so device modalities such as TouchID, FaceID, or PIN which are set up by the user. Best if all are accepted and one particular method isn't required/enforced.
- Use OAuth method to allow users to use third-party password managers for authentication.
- Two-factor authentication allows for multiple options to complete the second factor.
3.3.8 - Redundant Entry - Level A
Information previously entered or provided to the user to be entered again in a process and in the same user session is either auto-populated or available for the user to select.
Exceptions:
- Re-entering the information is essential.
- The information is required to ensure the security of the content.
- Previously entered information is no longer valid.
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
Note: This criterion has been deprecated for WCAG 2.2 and no longer applies.
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 Parsing4.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. Accessibility hints are utilized appropriately per the human interface guidelines for the operating system.
More Info on Name, Role, Value4.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