This document, “Guidance on Applying WCAG 2.2 to Mobile (WCAG2Mobile)”, describes how the Web Content Accessibility Guidelines (WCAG) version 2.2 [WCAG22] principles, guidelines, and success criteria can be applied to Mobile Applications, including but not limited to native mobile apps, mobile web apps and hybrid apps using web components inside native mobile apps. It provides informative guidance (guidance that is not normative and does not set requirements).
This document is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the Mobile Accessibility Overview.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is a W3C Group Note on “Guidance on Applying WCAG 2.2 to Mobile (WCAG2Mobile)”. The purpose of this work is to build upon "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile", but with a stronger focus on Mobile Applications and including changes made in WCAG 2.1 and 2.2.
To comment, file an issue in the W3C matf
GitHub repository. The Task Force requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive). In-progress updates to the guidelines can be viewed in the public editors’ draft.
This document was published by the Accessibility Guidelines Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
The Mobile Accessibility Task Force (MATF) is a task force of the Accessibility Guidelines Working Group (AG WG).
This document is an iteration on Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, published in February 2015 as First Public Working Draft. The document was intended to become a Group Note but it did not move to the next maturity stage. The most recent publication was an Editor's Draft in December 2018.
In the next years, the MATF ensured that mobile considerations were included in WCAG 2.1 and WCAG 2.2, such as:
In January 2024, the MATF regrouped and welcomed new participants to work on updated guidance for applying WCAG 2.2 to Mobile Applications.
This current document, “Guidance on Applying WCAG 2.2 to Mobile (WCAG2Mobile)” is specific to how WCAG applies to Mobile Applications, including but not limited to native mobile apps, mobile web apps and hybrid apps using web components inside native mobile apps.
WCAG2Mobile maps directly to the W3C supporting document, “Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)”, which was published as a Group Note in October 2024, describing how WCAG 2.2 could be applied to non-web documents and software. The intention of the MATF is to publish WCAG2Mobile as a Group Note, just like WCAG2ICT.
WCAG2ICT is organized to mirror the Principle, Guideline and Success Criterion structure of WCAG; this model is also used in WCAG2Mobile. WCAG2ICT clarifies when and how WCAG Level A and Level AA success criteria could be applied to non-web documents and software; WCAG2Mobile narrows the scope of this work to Mobile Applications.
This document provides informative guidance (guidance that is not normative and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to Mobile Applications. This document is a Group Note (in contrast to WCAG 2.2, which is a W3C Recommendation). Specifically, this document provides informative guidance on applying WCAG 2.2 Level A and AA success criteria to Mobile Applications, including but not limited to native mobile apps, mobile web apps and hybrid apps using web components inside native mobile apps.
When certain Web-specific terms or phrases like “web page(s)” were used in success criteria, those were replaced with mobile terms or phrases like “screen(s)” or “view(s)”. Additional notes were also provided to explain the terminology replacements.
A small number of success criteria are written to apply to “a set of web pages” or “multiple web pages” and depend upon all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 2 is a single web page, the task force agreed that the equivalent unit of conformance for mobile applications is a single screen within the application. It follows that an equivalent unit of evaluation for a “set of web pages” would be a “set of screens”, not, as previously interpreted in WCAG2ICT, as a “set of software”. These terms are defined in the Key Terms section of this document. See “set of screens” to determine when a group of screens in a mobile application are considered a set.
The glossary terms were also reviewed and most of them applied to mobile applications, as written. Some applied with additional notes or edits (largely related to phrases like “Web page(s)”), and a small number of terms were only used in Level AAA success criteria which are not addressed by the WCAG2Mobile Note at this time.
The following are out of scope for this document:
This document includes text quoted from the WCAG 2.2 principles, guidelines, success criteria, and glossary definition without any changes. This document also includes text quoted from the WCAG2ICT document. The guidance provided by this document for each principle, guideline, success criterion, and definition is preceded by a heading beginning with “Applying…”. This guidance was created by the Mobile Accessibility Task Force.
The following stylistic conventions are used in this document:
<details>
elements and visually styled with a border, and immediately follow the heading for the principle, guideline, or success criterion.<details>
elements and visually styled with a border, and immediately follow the WCAG quote.<ins>
elements visually styled as bold green text with a dotted underline.<cite>
elements visually styled as ordinary text with a dotted underline, and contain title attributes noting these are WCAG definitions. They turn blue with a yellow background when mouse or keyboard focus is placed over them.<cite>
elements visually styled as ordinary text with a dark gray underline.In this Editor's Draft, most of the existing sections have undergone significant Mobile Accessibility Task Force review and updates. The current Draft has been restructured to align with WCAG2ICT rather than continue with the structure and format of the 2015 Mobile Accessibility Mapping document.
With this perspective in mind, the following list highlights where this current document (WCAG2Mobile) differs from the 2015 Mobile Accessibility Mapping document to apply all success criteria of WCAG 2.0, WCAG 2.1, WCAG 2.2, and acknowledge the change to 4.1.1 Parsing to Mobile Applications:
Work In Progress. See: Key Terms section
The prior 2015 Mobile Working Draft Note included specific guidance on the following WCAG 2.0 success criteria for mobile, primarily for a mobile web context:
Supporting documentation in the Mobile Mapping Appendix included WCAG 2.0 Techniques that Apply to Mobile to address mobile web use cases for the rest of the WCAG 2.0 success criterion at the Level A, AA, and AAA levels as they were available in 2015 when the webpage was published. However, most listed techniques have limited application to native mobile applications and cross-platform frameworks like Flutter and React Native.
This document includes all WCAG 2.1 Level A and AA success criteria and guidelines:
This document includes all WCAG 2.2 Level A and AA success criteria:
New terms from WCAG 2.1 and 2.2:
Updated terms from WCAG2ICT for mobile context:
New Terms added to WCAG2Mobile:
WCAG2Mobile defines key glossary terms to refine the broader scope of WCAG2ICT for Mobile Applications. It introduces terms that do not exist in WCAG2ICT or WCAG but are important to define for a Mobile Application context.
“Content” and “user agent” are glossary terms from WCAG2ICT that need to be interpreted significantly differently when applied to Mobile Applications.
The glossary terms “document” and “software” in WCAG2ICT are replaced with the defined terms “screen” and “view”. The glossary terms “set of web pages”, “set of documents” and “set of software programs” are replaced with the defined term “set of screens”.
The term “accessibility services of platform software”, introduced by WCAG2ICT, has been modified to reflect its different use in Mobile Applications. Additionally, “closed functionality” has a different meaning in the context of Mobile Applications.
The remaining glossary terms from WCAG2ICT and WCAG 2 are addressed in WCAG2ICT: Comments on Definitions in WCAG 2 Glossary.
Terms defined and used in WCAG2Mobile are applicable only to the interpretation of the guidance in this document. The particular definitions should not be interpreted as having applicability to situations beyond the scope of WCAG2Mobile. Further information on usage of these terms follows.
Work in Progress. See Issues labeled as 'definition' on GitHub.
Additional information about participation in the Mobile Accessibility Task Force (MATF) can be found on the MATF home page.
This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
Comments by Principle, Guideline and Success Criterion
The sections that follow are organized according to the principles, guidelines and success criteria from WCAG 2.2. The text of each principle, guideline and success criterion from WCAG 2.2 is provided as quoted text. Following that, the WCAG2ICT guidance is provided as quoted text. Next, the WCAG2Mobile guidance itself is provided.
Work in Progress. The document currently only includes guidance for success criteria. The guidance for principles and guidelines will be added at a later stage.
Success Criterion 1.1.1 Non-text Content
(Level A)
WCAG: Success Criterion 1.1.1 Non-text Content
WCAG2ICT: Applying SC 1.1.1 Non-text Content to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1.
Not all mobile platforms provide a way to programmatically associate a label with non-text content.
Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded)
(Level A)
WCAG: Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded)
WCAG2ICT: Applying SC 1.2.1 Audio-only and Video-only (Prerecorded) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1.
The alternative can be provided directly in the view – or provided in an alternate version that meets the success criteria.
Success Criterion 1.2.2 Captions (Prerecorded)
(Level A)
WCAG: Success Criterion 1.2.2 Captions (Prerecorded)
WCAG2ICT: Applying SC 1.2.2 Captions (Prerecorded) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.2.
The WCAG 2 definition of “captions” notes that “in some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.
Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded)
(Level A)
WCAG: Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded)
WCAG2ICT: Applying SC 1.2.3 Audio Description or Media Alternative (Prerecorded) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3.
The WCAG 2 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.
Secondary or alternate audio tracks are commonly used for this purpose.
Success Criterion 1.2.4 Captions (Live)
(Level AA)
WCAG: Success Criterion 1.2.4 Captions (Live)
WCAG2ICT: Applying SC 1.2.4 Captions (Live) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4.
The WCAG 2 definition of “captions” notes that “In some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.
Success Criterion 1.2.5 Audio Description (Prerecorded)
(Level AA)
WCAG: Success Criterion 1.2.5 Audio Description (Prerecorded)
WCAG2ICT: Applying SC 1.2.5 Audio Description (Prerecorded) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5.
The WCAG 2 definition of “audio description” says that audio description is “also called ‘video description’ and ‘descriptive narration’”.
Secondary or alternate audio tracks are commonly used for this purpose.
Success Criterion 1.3.1 Info and Relationships
(Level A)
WCAG: Success Criterion 1.3.1 Info and Relationships
WCAG2ICT: Applying SC 1.3.1 Info and Relationships to Non-Web Documents and Software
Placeholder
Read issue #1 on GitHub
Success Criterion 1.3.2 Meaningful Sequence
(Level A)
WCAG: Success Criterion 1.3.2 Meaningful Sequence
WCAG2ICT: Applying SC 1.3.2 Meaningful Sequence to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
Grouping related elements using semantic containers helps ensure a meaningful reading sequence.
Success Criterion 1.3.3 Sensory Characteristics
(Level A)
WCAG: Success Criterion 1.3.3 Sensory Characteristics
WCAG2ICT: Applying SC Sensory Characteristics 1.3.3 to Non-Web Documents and Software
Placeholder
Read issue #24 on GitHub
Success Criterion 1.3.4 Orientation
(Level AA)
WCAG: Success Criterion 1.3.4 Orientation
WCAG2ICT: Applying SC 1.3.4 Orientation to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
It is considered a best practice to support all available orientations, such as as portrait, portrait (reversed), landscape, and landscape (reversed).
Success Criterion 1.3.5 Identify Input Purpose
(Level AA)
WCAG: Success Criterion 1.3.5 Identify Input Purpose
WCAG2ICT: Applying SC 1.3.5 Identify Input Purpose to Non-Web Documents and Software
Placeholder
Read issue #2 on GitHub
Success Criterion 1.4.1 Use of Color
(Level A)
WCAG: Success Criterion 1.4.1 Use of Color
WCAG2ICT: Applying SC 1.4.1 Use of Color to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1.
If a mobile platform’s built-in distinction relies only on color, additional visual means must convey the information.
Success Criterion 1.4.2 Audio Control
(Level A)
WCAG: Success Criterion 1.4.2 Audio Control
WCAG2ICT: Applying SC 1.4.2 Audio Control to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2, replacing “on a Web page” with “in a view”, “any content” with “any view”, “whole page” with “whole view”, and “on the Web page” with “in the view”; and removing “See Conformance Requirement 5: Non-Interference”.
With these substitutions, it would read:
1.4.2 Audio Control: If any audio in a view plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
Since any view that does not meet this success criterion can interfere with a user's ability to use the whole view, all content in the view (whether it is used to meet other success criteria or not) must meet this success criterion.
Success Criterion 1.4.3 Contrast (Minimum)
(Level AA)
WCAG: Success Criterion 1.4.3 Contrast (Minimum)
WCAG2ICT: Applying SC 1.4.3 Contrast Minimum to Non-Web Documents and Software
Placeholder
Read issue #28 on GitHub
Success Criterion 1.4.4 Resize Text
(Level AA)
WCAG: Success Criterion 1.4.4 Resize Text
WCAG2ICT: Applying SC 1.4.4 Resize Text to Non-Web Documents and Software
Placeholder
Read issue #3 on GitHub
Success Criterion 1.4.5 Images of Text
(Level AA)
WCAG: Success Criterion 1.4.5 Images of Text
WCAG2ICT: Applying SC 1.4.5 Images of Text to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5.
Success Criterion 1.4.10 Reflow
(Level AA)
WCAG: Success Criterion 1.4.10 Reflow
WCAG2ICT: Applying SC 1.4.10 Reflow to Non-Web Documents and Software
Placeholder
Read issue #4 on GitHub
Success Criterion 1.4.11 Non-text Contrast
(Level AA)
WCAG: Success Criterion 1.4.11 Non-text Contrast
WCAG2ICT: Applying SC 1.4.11 Non-text Contrast to Non-Web Documents and Software
Placeholder
Read issue #49 on GitHub
Success Criterion 1.4.12 Text Spacing
(Level AA)
WCAG: Success Criterion 1.4.12 Text Spacing
WCAG2ICT: Applying SC 1.4.12 Text Spacing to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.12, replacing "content implemented using markup languages" with "content".
With these substitutions, it would read:
1.4.12 Text Spacing: In content that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.
Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system.
If a mobile platform does not include a way for users to override text style properties, this success criterion is not applicable.
Success Criterion 1.4.13 Content on Hover or Focus
(Level AA)
WCAG: Success Criterion 1.4.13 Content on Hover or Focus
WCAG2ICT: Applying SC 1.4.13 Content on Hover or Focus to Non-Web Documents and Software
Placeholder
Read issue #6 on GitHub
Success Criterion 2.1.1 Keyboard
(Level A)
WCAG: Success Criterion 2.1.1 Keyboard
WCAG2ICT: Applying SC 2.1.1 Keyboard to Non-Web Documents and Software
Placeholder
Read issue #12 on GitHub
Success Criterion 2.1.2 No Keyboard Trap
(Level A)
WCAG: Success Criterion 2.1.2 No Keyboard Trap
WCAG2ICT: Applying SC 2.1.2 No Keyboard Trap to Non-Web Documents and Software
Placeholder
Read issue #30 on GitHub
Success Criterion 2.1.4 Character Key Shortcuts
(Level A)
WCAG: Success Criterion 2.1.4 Character Key Shortcuts
WCAG2ICT: Applying SC 2.1.4 Character Key Shortcuts to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4.
The WCAG2ICT interpretation is that a long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details.
The WCAG2Mobile interpretation aligns with WCAG2ICT, emphasizing that long presses and other accessibility features are not addressed by this success criterion.
Success Criterion 2.2.1 Timing Adjustable
(Level A)
WCAG: Success Criterion 2.2.1 Timing Adjustable
WCAG2ICT: Applying SC 2.2.1 Timing Adjustable to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.1, replacing “the content” with “views”.
With this substitution, it would read:
2.2.1 Timing Adjustable: For each time limit that is set by views, at least one of the following is true:
This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.
Success Criterion 2.2.2 Pause, Stop, Hide
(Level A)
WCAG: Success Criterion 2.2.2 Pause, Stop, Hide
WCAG2ICT: Applying SC 2.2.2 Pause, Stop, Hide to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2, replacing “page” and “Web page” with “view” and removing “See Conformance Requirement 5: Non-Interference” in Note 2 of the success criterion.
With these substitutions, it would read:
2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:
Moving, blinking, scrolling
For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
Auto-updating
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
For requirements related to flickering or flashing content, refer to Guideline 2.3.
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole view, all content on the views (whether it is used to meet other success criteria or not) must meet this success criterion.
Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
While the success criterion uses the term “information”, the WCAG 2 Intent section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.
Success Criterion 2.3.1 Three Flashes or Below Threshold
(Level A)
WCAG: Success Criterion 2.3.1 Three Flashes or Below Threshold
WCAG2ICT: Applying SC 2.3.1 Three Flashes or Below Threshold to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1, replacing “Web pages” with “views”, “the whole page” with “the whole view”, and “the Web page” with “the view”; and removing “See Conformance Requirement 5: Non-Interference”.
With these substitutions, it would read:
2.3.1 Three Flashes or Below Threshold: Views do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole view, all content on the view (whether it is used to meet other success criteria or not) must meet this success criterion.
Success Criterion 2.4.1 Bypass Blocks
(Level A)
WCAG: Success Criterion 2.4.1 Bypass Blocks
WCAG2ICT: Applying SC 2.4.1 Bypass Blocks to Non-Web Documents and Software
Placeholder
Read issue #8 on GitHub
Success Criterion 2.4.2 Page Titled
(Level A)
WCAG: Success Criterion 2.4.2 Page Titled
WCAG2ICT: Applying SC 2.4.2 Page Titled to Non-Web Documents and Software
Placeholder
Read issue #9 on GitHub
Success Criterion 2.4.3 Focus Order
(Level A)
WCAG: Success Criterion 2.4.3 Focus Order
WCAG2ICT: Applying SC 2.4.3 Focus Order to Non-Web Documents and Software
Placeholder
Read issue #35 on GitHub
Success Criterion 2.4.4 Link Purpose (In Context)
(Level A)
WCAG: Success Criterion 2.4.4 Link Purpose (In Context)
WCAG2ICT: Applying SC 2.4.4 Link Purpose (In Context) to Non-Web Documents and Software
Placeholder
Read issue #36 on GitHub
Success Criterion 2.4.5 Multiple Ways
(Level AA)
WCAG: Success Criterion 2.4.5 Multiple Ways
WCAG2ICT: Applying SC 2.4.5 Multiple Ways to Non-Web Documents and Software
Placeholder
Read issue #13 on GitHub
Success Criterion 2.4.6 Headings and Labels
(Level AA)
WCAG: Success Criterion 2.4.6 Headings and Labels
WCAG2ICT: Applying SC 2.4.6 Headings and Labels to Non-Web Documents and Software
Placeholder
Read issue #50 on GitHub
Success Criterion 2.4.7 Focus Visible
(Level AA)
WCAG: Success Criterion 2.4.7 Focus Visible
WCAG2ICT: Applying SC 2.4.7 Focus Visible to Non-Web Documents and Software
Placeholder
Read issue #51 on GitHub
Success Criterion 2.4.11 Focus Not Obscured (Minimum)
(Level AA)
WCAG: Success Criterion 2.4.11 Focus Not Obscured (Minimum)
WCAG2ICT: Applying SC 2.4.11 Focus not Obscured to Non-Web Documents and Software
Placeholder
Read issue #52 on GitHub
Success Criterion 2.5.1 Pointer Gestures
(Level A)
WCAG: Success Criterion 2.5.1 Pointer Gestures
WCAG2ICT: Applying SC 2.5.1 Pointer Gestures to Non-Web Documents and Software
Placeholder
Read issue #37 on GitHub
Success Criterion 2.5.2 Pointer Cancellation
(Level A)
WCAG: Success Criterion 2.5.2 Pointer Cancellation
WCAG2ICT: Applying SC 2.5.2 Pointer Cancellation to Non-Web Documents and Software
Placeholder
Read issue #38 on GitHub
Success Criterion 2.5.3 Label in Name
(Level A)
WCAG: Success Criterion 2.5.3 Label in Name
WCAG2ICT: Applying SC 2.5.3 Label in Name to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3.
Success Criterion 2.5.4 Motion Actuation
(Level A)
WCAG: Success Criterion 2.5.4 Motion Actuation
WCAG2ICT: Applying SC 2.5.4 Motion Actuation to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.4.
Success Criterion 2.5.7 Dragging Movements
(Level AA)
WCAG: Success Criterion 2.5.7 Dragging Movements
WCAG2ICT: Applying SC 2.5.7 Dragging Movements to Non-Web Documents and Software
Placeholder
Read issue #53 on GitHub
Success Criterion 2.5.8 Target Size (Minimum)
(Level AA)
WCAG: Success Criterion 2.5.8 Target Size (Minimum)
WCAG2ICT: Applying SC 2.5.8 Target Size (Minimum) to Non-Web Documents and Software:
Placeholder
Read issue #10 on GitHub
Success Criterion 3.1.1 Language of Page
(Level A)
WCAG: Success Criterion 3.1.1 Language of Page
WCAG2ICT: Applying SC 3.1.1 Language of Page to Non-Web Documents and Software
Placeholder
Read issue #14 on GitHub
Success Criterion 3.1.2 Language of Parts
(Level AA)
WCAG: Success Criterion 3.1.2 Language of Parts
WCAG2ICT: Applying SC 3.1.2 Language of Parts to Non-Web Documents and Software
Placeholder
Read issue #15 on GitHub
Success Criterion 3.2.1 On Focus
(Level A)
WCAG: Success Criterion 3.2.1 On Focus
WCAG2ICT: Applying SC 3.2.1 On Focus to Non-Web Documents and Software
Placeholder
Read issue #41 on GitHub
Success Criterion 3.2.2 On Input
(Level A)
WCAG: Success Criterion 3.2.2 On Input
WCAG2ICT: Applying SC 3.2.2 On Input to Non-Web Documents and Software
Placeholder
Read issue #42 on GitHub
Success Criterion 3.2.3 Consistent Navigation
(Level AA)
WCAG: Success Criterion 3.2.3 Consistent Navigation
WCAG2ICT: Applying SC 3.2.3 Consistent Navigation to Non-Web Documents and Software
Placeholder
Read issue #54 on GitHub
Success Criterion 3.2.4 Consistent Identification
(Level AA)
WCAG: Success Criterion 3.2.4 Consistent Identification
WCAG2ICT: Applying SC 3.2.4 Consistent Identification to Non-Web Documents and Software
Placeholder
Read issue #55 on GitHub
Success Criterion 3.2.6 Consistent Help
(Level A)
WCAG: Success Criterion 3.2.6 Consistent Help
WCAG2ICT: Applying SC 3.2.6 Consistent Help to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.6, replacing "web page(s)" and "page(s)" with "view(s)" and "CSS break-point" with "break-point".
With these substitutions, it would read:
3.2.6 Consistent Help: If a view contains any of the following help mechanisms, and those mechanisms are repeated on multiple views within a set of views, they occur in the same order relative to other view content, unless a change is initiated by the user:
Help mechanisms may be provided directly on the view, or may be provided via a direct link to a different view containing the information.
For this success criterion, "the same order relative to other view content" can be thought of as how the content is ordered when the view is serialized. The visual position of a help mechanism is likely to be consistent across views for the same view variation (e.g., break-point). The user can initiate a change, such as changing the view's zoom or orientation, which may trigger a different view variation. This criterion is concerned with relative order across views displayed in the same view variation (e.g., same zoom level and orientation).
Success Criterion 3.3.1 Error Identification
(Level A)
WCAG: Success Criterion 3.3.1 Error Identification
WCAG2ICT: Applying SC 3.3.1 Error Identification to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1.
Success Criterion 3.3.2 Labels or Instructions
(Level A)
WCAG: Success Criterion 3.3.2 Labels or Instructions
WCAG2ICT: Applying SC 3.3.2 Labels or Instructions to Non-Web Documents and Software
Placeholder
Read issue #45 on GitHub
Success Criterion 3.3.3 Error Suggestion
(Level AA)
WCAG: Success Criterion 3.3.3 Error Suggestion
WCAG2ICT: Applying SC 3.3.3 Error Suggestion to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3.
Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
(Level AA)
WCAG: Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
WCAG2ICT: Applying SC 3.3.4 Error Prevention (Legal, Financial, Data) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 replacing “web pages” with “views”.
With this substitution, it would read:
3.3.4 Error Prevention (Legal, Financial, Data): For views that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
Success Criterion 3.3.7 Redundant Entry
(Level A)
WCAG: Success Criterion 3.3.7 Redundant Entry
WCAG2ICT: Applying SC 3.3.7 Redundant Entry to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.7.
Success Criterion 3.3.8 Accessible Authentication (Minimum)
(Level AA)
WCAG: Success Criterion 3.3.8 Accessible Authentication (Minimum)
WCAG2ICT: Applying SC 3.3.8 Accessible Authentication (Minimum) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.8, replacing “the Web site” with “a view”.
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
Alternative Another authentication method that does not rely on a cognitive function test.
Mechanism A mechanism is available to assist the user in completing the cognitive function test.
Object Recognition The cognitive function test is to recognize objects.
Personal Content The cognitive function test is to identify non-text content the user provided to a view.
“Object recognition” and “Personal content” may be represented by images, video, or audio.
Examples of mechanisms that satisfy this criterion include: support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing.
If the non-web software is an application, passwords used to unlock the underlying platform software are out of scope for this requirement as these are not up to a software application’s author.
Success Criterion 4.1.1 Parsing
(Level A)
WCAG: Success Criterion 4.1.1 Parsing (Obsolete and removed)
WCAG2ICT: Applying SC 4.1.1 Parsing (Obsolete and removed) (WCAG 2.2) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.1, meaning that it has been marked as obsolete and removed.
(Obsolete and removed)
WCAG 2.2 has made this success criterion obsolete and removed it as a requirement in the standard. Therefore, the interpretation of this success criterion for Mobile Applications has been removed.
Success Criterion 4.1.2 Name, Role, Value
(Level A)
WCAG: Success Criterion 4.1.2 Name, Role, Value
WCAG2ICT: Applying SC 4.1.2 Name, Role, Value to Non-Web Documents and Software
Placeholder
Read issue #48 on GitHub
Success Criterion 4.1.3 Status Messages
(Level AA)
WCAG: Success Criterion 4.1.3 Status Messages
WCAG2ICT: Applying SC 4.1.3 Status Messages to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3, removing “implemented using markup languages”.
With these substitutions, it would read:
4.1.3 Status Messages: In content, 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 typically enabled through the use of accessibility services of the user agent or platform software.