Does WCAG 2.2 apply to native apps
Posted on by Steve Faulkner in Design and development, Standards, Testing
A big question for many organisations is if WCAG 2.2 applies to native apps. In this post we explore what does and doesn't apply.
With enforcement of the European Accessibility Act (EAA) due in 2025, many organisations that are economically active in Europe are working to ensure their apps are accessible. The timely update by the W3C to the Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) will help in this endeavour.
Does WCAG 2.2 apply to native apps? Yes, mostly.
How and where it applies (informatively) is detailed in Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)
Note about WCAG2ICT
WCAG2ICT provides non-normative guidance on how to apply web accessibility guidelines (WCAG) to non-web technologies:
This document (WCAG2ICT) 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 non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, WCAG 2.1, and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.
Mapping WCAG
Below is what I think is the pertinent information for Level A/AA criteria in an abbreviated form and includes links to APPT solutions for:
- Android
- Jetpack Compose
- iOS
- SwiftUI
- Flutter
- React Native
- .NET MAUI
- Xamarin
WCAG Level A for apps
| Criteria & Solutions | Applies | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content , Implementation solutions for 1.1.1 |  |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1
See also the Comments on Closed Functionality. |
| 1.2.1 Audio-only and Video-only (Prerecorded), Implementation solutions for 1.2.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1.
See also the Comments on Closed Functionality. |
| 1.2.2 Captions (Prerecorded), Implementation solutions for 1.2.2 | |
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...” |
| 1.2.3 Audio Description or Media Alternative (Prerecorded), Implementation solutions for 1.2.3 | |
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’”.Note 2: Secondary or alternate audio tracks are commonly used for this purpose.See also the Comments on Closed Functionality. |
| 1.3.1 Info and Relationships, Implementation solutions for 1.3.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.1.
In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software.See also the Comments on Closed Functionality. |
| 1.3.2 Meaningful Sequence, Implementation solutions for 1.3.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.2.
See also the Comments on Closed Functionality. |
| 1.3.3 Sensory Characteristics, Implementation solutions for 1.3.3 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.3. |
| 1.4.1 Use of Color, Implementation solutions for 1.4.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1. |
| 1.4.2 Audio Control, Implementation solutions for 1.4.2 | |
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 non-web document or software”, "any content" with "any part of a non-web document or software”, "whole page" with "whole document or software”, and "on the Web page" with "in the document or software”; and removing "See Conformance Requirement 5: Non-Interference” |
| 2.1.1 Keyboard, Implementation solutions for 2.1.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1.
Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input)...Note 2: This success criterion does not imply that software always needs to directly support a keyboard or "keyboard interface”. Nor does it imply that software always needs to provide a virtual keyboard.See also the Comments on Closed Functionality. |
| 2.1.2 No Keyboard Trap, Implementation solutions for 2.1.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.2, replacing "page" with "non-web document or software" and "on the Web page" with "in the non-web document or software"; and removing "See Conformance Requirement 5: Non-Interference”.See also Note 1, Note 2, Note 3 and Comments on Closed Functionality. |
| 2.1.4 Character Key Shortcuts, Implementation solutions for 2.1.4 | |
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.See also the Comments on Closed Functionality. |
| 2.2.1 Timing Adjustable, Implementation solutions for 2.2.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.1, replacing "the content" with "non-web documents or software”. |
| 2.2.2 Pause, Stop, Hide, Implementation solutions for 2.2.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2, replacing "page" and "Web page" with "non-web documents and software" and removing "See Conformance Requirement 5: Non-Interference" in Note 2 of the success criterion.See also Note 1, Note 2, Note 3, Note 4 and Note 5 |
| 2.3.1 Three Flashes or Below Threshold, Implementation solutions for 2.3.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1, replacing "Web pages" with "non-web documents or software", "the whole page" with "the whole non-web document or software”, and "the Web page" with "the non-web document or software”; and removing "See Conformance Requirement 5: Non-Interference”.See also the Note |
| 2.4.1 Bypass Blocks, Implementation solutions for 2.4.1 |  |
This does not apply within an app, but may apply across a set of related apps. |
| 2.4.2 Page Titled, Implementation solutions for 2.4.2 | |
Appears to apply to whole applications rather than individual screens. Although the, implementation advice available appears to provide individual screen level methods.
Also see Issue #437 and Mobile Content Accessibility Guidelines (MCAG) 3.1.1. Screen Titled |
| 2.4.3 Focus Order, Implementation solutions for 2.4.3 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.3 replacing "a Web page" with "non-web documents or software”. |
| 2.4.4 Link Purpose (In Context), Implementation solutions for 2.4.4 | |
This applies directly as written and as described in Intent from Understanding Success Criterion 2.4.4.Note: In software, a "link" is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.) |
| 2.5.1 Pointer Gestures, Implementation solutions for 2.5.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.1 |
| 2.5.2 Pointer Cancellation, Implementation solutions for 2.5.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.2, making changes to the notes for non-web documents by replacing "web content" with "content", for non-web software applications by replacing "web content that interprets" with "user agents and other software applications that interpret" and "user agent" with "underlying platform software", and for non-web platform software by replacing "web content" with "platform software".See also Note 1, Note 2, Note 3, Note 4, Note 5, Note 6 and Comments on Closed Functionality. |
| 2.5.3 Label in Name, Implementation solutions for 2.5.3 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3. |
| 2.5.4 Motion Actuation, Implementation solutions for 2.5.4 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.4.
See also the Comments on Closed Functionality. |
| 3.1.1 Language of Page, Implementation solutions for 3.1.1 | |
Applies to application as a whole rather than individual screens
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.1 replacing "each web page" with "non-web documents or software”. Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language.See also the Comments on Closed Functionality. |
| 3.2.1 On Focus, Implementation solutions for 3.2.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.1
See also, the Note |
| 3.2.2 On Input, Implementation solutions for 3.2.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.2 |
| 3.2.6 Consistent Help, Implementation solutions for 3.2.6 | |
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 "non-web document(s) or software program(s)", "set of Web pages" with "set of non-web documents or set of software programs", "page content" with "content", "on the page" with "in the non-web document or software", "page is serialized" with "non-web document or software content is serialized", "different page" with "different non-web document, software, or Web page", and "page variation" with "content layout variation".See also Note 1, Note 2 and Note 3 |
| 3.3.1 Error Identification, Implementation solutions for 3.3.1 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1
See also the Comments on Closed Functionality. |
| 3.3.2 Labels or Instructions, Implementation solutions for 3.3.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.2. |
| 3.3.7 Redundant Entry, Implementation solutions for 3.3.7 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.7. |
| 4.1.1 Parsing | not applicable |
2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata |
| 4.1.2 Name, Role, Value, Implementation solutions for 4.1.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.2, replacing the note with: "This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.”.See also Note 1, Note 2 and Note 3 See also the Comments on Closed Functionality. |
WCAG Level AA for apps
| Criteria & Solutions | Applies | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live), Implementation reference for 1.2.4 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4.
See also the Note. |
| 1.2.5 Audio Description (Prerecorded), Implementation solutions for 1.25 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5. |
| 1.3.4 Orientation, Implementation solutions for 1.34 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
Content that is only used on hardware with a fixed display orientation or that has no sensor to detect or change the orientation is covered under the essential exception and does not need to provide support for orientation changes.See also the Comments on Closed Functionality. |
| 1.3.5 Identify Input Purpose, Implementation solutions for 1.35 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5.
Non-web software and non-web document technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion.Note 2: For non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2 section Input Purposes for User Interface Components that are supported by the technology used.See also the Comments on Closed Functionality. |
| 1.4.3 Contrast (Minimum), Implementation solutions for 1.43 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.3. See also the Comments on Closed Functionality. |
| 1.4.4 Resize text, Implementation solutions for 1.4.4 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4.
The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the application works with the platform accessibility features to meet this success criterion.Note 2: For non-web software, there may be cases where the platform does not scale all text up to 200%. In such cases, authors are encouraged to meet user needs by scaling text to the extent supported by user settings in the platform.See also the Comments on Closed Functionality. |
| 1.4.5 Images of Text, Implementation solutions for 1.4.5 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5. See also the Comments on Closed Functionality. |
| 1.4.10 Reflow, Implementation solutions for 1.4.10 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.10, replacing “web content” with “content”.Editors Note:The WCAG2ICT Task Force made changes to give additional guidance around how 1.4.10 Reflow should be applied to non-web software in response to public comments.Refer directly to the WCAG2ICT documentation: Applying SC 1.4.10 Reflow to Non-Web Documents and Software. |
| 1.4.11 Non-text Contrast, Implementation solutions for 1.4.11 | |
This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.11, replacing "user agent" with "user agent or platform software.
An example of appearance modification by the author is content that sets the visual style of a control, such as a color or border, to differ from the default style for the user agent or platform.See also the Comments on Closed Functionality. |
| 1.4.12 Text Spacing, Implementation solutions for 1.4.12 | |
This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12.
See also Note 1: This success criterion only applies to non-web documents and software that are implemented using markup languages and allow the user to modify these text spacing properties.Note 2: "Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron applications or iOS application Web views), XAML, XML (e.g., in Android application layouts), and XUL.Note 3: There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, an eBook technology may have an available user agent that allows users to override document text styles, or a software application may provide a "user style sheet" facility to modify the appearance of the software's own user interface. This success criterion does not mean that documents and software need to implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the success criterion requires that content respond appropriately to it.See also the Comments on Closed Functionality. |
| 1.4.13 Content on Hover or Focus, Implementation solutions for 1.4.13 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.13, replacing "user agent" with "user agent or platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes".See also Note 1: Examples of additional content controlled by the [user agent or platform software] include [tooltips] created through use of [user interface object attributes]. |
| 2.4.5 Multiple Ways | |
This applies directly as written and described in Intent from Understanding Success Criterion 2.4.5, replacing “set of Web pages” with “set of non-web documents” and “set of software programs”.
See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.See also Note 2, Note 3, Note 4, and Note 5 See also the Comments on Closed Functionality. |
| 2.4.6 Headings and Labels, Implementation solutions for 2.4.6 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.6.
Note: In software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with. |
| 2.4.7 Focus Visible, Implementation solutions for 2.4.7 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.7. See also the Comments on Closed Functionality. |
| 2.4.11 Focus Not Obscured (Minimum), Implementation solutions for 2.4.11 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.11. |
| 2.5.7 Dragging Movements, Implementation solutions for 2.5.7 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.7, replacing "user agent" with "user agent or platform software", and making changes to the notes for non-web documents by replacing “web content” with "content", for non-web software applications by replacing "web content that interprets" with "user agents and other software applications that interpret" and "user agent" with "underlying platform software", and for non-web platform software by replacing "web content" with "platform software".See also Note 1, Note 2, Note 3, and Note 4. |
| 2.5.8 Target Size (Minimum), Implementation solutions for 2.5.8 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8, replacing "user agent" with "user agent or platform software" and "on the same page" with "in the same non-web document or software".See also Note 1: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.Note 2: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.Note 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to Non-Web Documents and Software. |
| 3.1.2 Language of Parts, Implementation solutions for 3.1.2 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.2 replacing “content” with “non-web document or software”.
See also Note 1: There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to meet this success criterion with those technologies.See also the Comments on Closed Functionality. |
| 3.2.3 Consistent Navigation | |
This applies directly as written and described in Intent from Understanding Success Criterion 3.2.3, replacing “set of Web pages” with “set of non-web documents” and “set of software programs”.See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.See also Note 2. See also the Comments on Closed Functionality. |
| 3.2.4 Consistent Identification | |
This applies directly as written and described in Intent from Understanding Success Criterion 3.2.4, replacing “set of web pages” with “set of non-web documents” and “set of software programs”.See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.and Note 2 |
| 3.3.3 Error Suggestion, Implementation solutions for 3.3.3 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3. |
| 3.3.4 Error Prevention (Legal, Financial, Data), Implementation solutions for 3.3.4 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 replacing “web pages” with “non-web documents or software”. |
| 3.3.8 Accessible Authentication (Minimum), Implementation solutions for 3.3.8 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.8, “the Web site” with “a Web site, non-web document, or software”.Note 1: "Object recognition" and "Personal content" may be represented by images, video, or audio.Note 2 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.Note 3: 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.Note 4 There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password on when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to meet this success criterion.See also the Comments on Closed Functionality. |
| 4.1.3 Status Messages, Implementation solutions for 4.1.3 | |
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3. |
Next steps
For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.