Peaky WCAG (Level AA) BANG for your APP A11Y BUCK

Patrick wearing a flat cap

Self portrait of Peak WCAG Trash Panda Patrick Lauke

Does WCAG 2.2 Level AA apply to Native apps?

yes, mostly

How/where it (non-normatively) applies is detailed in Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)

Below is what I think is the pertinent information for Level AA criteria in an abbreviated form, which is hopefully useful.

Also see: WCAG (Level A) BANG for your APP A11Y BUCK

With added APPT solutions for apps: Android, Jetpack Compose, iOS, SwiftUI, Flutter, React Nativ, .NET MAUI, Xamarin:

WCAG Level AA for apps
Criteria	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. See also, Note 1 and Note 2
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. Note 1: 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. Note 1: 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. Note 1: 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. Note 1: 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. , Note 2, Note 3, Note 4, 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. and 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.