What WCAG 2.2 Means for Native Mobile Accessibility
The Web Content Accessibility Guidelines (WCAG) have been the standard for digital accessibility the world around for two decades. While it wasn’t created to specifically govern native mobile applications, many of the guidelines can be applied either directly or with some thoughtful interpretation. The W3C is preparing to publish version 2.2 of WCAG which adds several new success criteria extending requirements for users with low vision, cognitive impairments, and limited fine motor skills. Below we’ll cover if and how each of them can be applied to native mobile applications.
New Success Criteria
The WCAG 2.2 proposal currently has nine new success criteria. These are still in a review stage, so it is not guaranteed all of them will make it into the final recommendation. The list of new success criteria, as of the Candidate Recommendation of September 6, 2022 is as follows:
2.4.11 Focus Appearance (Minimum) (Level AA)
2.4.12 Focus Not Obscured (Minimum) (Level AA)
2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
2.5.7 Dragging Movements (Level AA)
2.5.8 Target Size (Minimum) (Level AA)
3.2.6 Consistent Help (Level A)
3.3.7 Accessible Authentication (Level AA)
3.3.8 Accessible Authentication (No Exception) (Level AAA)
3.3.9 Redundant Entry (Level A)
Focus Appearance
This success criterion ensures that sighted users who navigate a web page using a keyboard have a clearly visible “focus indicator” that shows where they are in the page. The corollary of this for native mobile applications is a user that navigates using assistive technology such as Switch Control or Full Keyboard Access for iOS or Switch Access for Android. On both platforms, the color, size, and shape of the focus indicator is dictated by the operating system. This means that a developer cannot change what the focus indicator looks like in their application, and therefore are granted an exception for this criterion. This is the only new success criterion that can’t be applied to native mobile applications.
Focus Not Obscured
Similar to Focus Appearance, these two success criteria address the ability for a sighted keyboard user to see where their current point of focus is. Again, in the case of native mobile applications, keyboard focus can be interpreted as the focus indicator for various assistive technology such as Switch Control/Access, Full Keyboard Access, or Voice Control/Access. The minimum criterion states when a component receives focus, it is not entirely covered by other components. The enhanced criterion requires when a component receives focus, no part of the indicator is hidden by other components. Both, with the broader interpretation of keyboard focus, can be applied to native mobile apps. An example of this issue occurring in websites is when a component that receives focus is covered by a sticky header or footer. This can be translated for native mobile apps when a component that receives focus is hidden by a top or bottom bar.
Dragging Movements
Drag and drop actions are likely more common in native mobile applications than on web pages. For example, envision curating a playlist on Spotify or Apple Music, you can change the order of the songs by dragging and dropping them into the desired place. These interactions require fairly precise motions and the ability to hold a finger on the screen without accidentally releasing, which can be difficult for people with motor disabilities. This success criterion requires that all actions that use dragging movements can also be achieved with a single pointer. In the case of native mobile apps, that single pointer can be interpreted as tapping once with a finger.
Target Size
The smaller a control is, the more difficult it is to activate, especially for people with reduced fine motor skills. This SC requires a minimum target size of 24×24 CSS pixels or minimum spacing of 24×24 CSS pixels for certain controls. This holds true for native mobile applications, however the success criterion can’t be directly applied since it is defined using CSS pixels. CSS does not exist in native mobile applications, so this guideline needs to be adapted for iOS and Android pixel scales. For iOS, 24 CSS pixels can be replaced with 24pt, and for Android 24 DP.
Consistent Help
This success criterion requires that if any web pages in a set provide a form of help (such as contact details or FAQ), at least one form of help is included in the same relative place on each page where that help happens to appear. This requirement will make it easier for users to find help when they need it. While the requirement explicitly mentions web pages, this can be interpreted as screens in a native mobile app.
Accessible Authentication
Signing into a website or app can be a struggle when users have to have their username and password memorized and/or transcribe a two-factor authentication (2FA) code from a text message. These success criteria require that authentication be possible without these cognitive tests or a mechanism be provided to assist users with the tests. This guideline can be directly applied to native mobile apps. iOS and Android both have features that can assist users in completing such cognitive tests for authentication. For example, iOS apps can support Keychain, Apple’s password manager, to alleviate users from memorizing usernames and passwords. On Android, Google’s Messages app provides a button to copy the security code from a 2FA text message in the notification.
Redundant Entry
Some forms require information to be input more than once, for example a shipping and billing address. This success criterion requires mechanisms be available such as auto population to reduce the strain of repeatedly typing. This criterion can be directly applied to native mobile applications as there is no web specific terminology used in the guideline.
Publication
WCAG 2.2 is expected to be published as an official W3C Recommendation by the end of 2022. As regulators pick up this update, we may slowly start to see this becoming a legal requirement in various countries from 2023 onward.
Deque is planning to make WCAG 2.2 available as an option for native mobile audits shortly after it is available.
