Implications of WCAG 2.2 for Native Mobile Accessibility

WCAG 2.2 for Native Mobile Accessibility

For almost two decades, the Web Content Accessibility Guidelines (WCAG) have set the bar for digital accessibility everywhere in the globe. While it wasn’t developed with native mobile apps in mind, you can still apply many of the principles with a little creativity. W3C is getting ready to release WCAG 2.2, which includes new success criteria that expand accessibility needs for users with low vision, cognitive impairments, and limited fine motor skills. In this blog, we will explore how they may be applied in native mobile apps.

Which are the newly proposed success criteria in WCAG 2.2?

There are presently nine proposed success criteria for WCAG 2.2. All of these are still being reviewed, therefore their inclusion in the final suggestion cannot be assured at this time. The Candidate Recommendation as of September 6, 2022, are as follows:

Now let us briefly explain every success criteria that may apply to native mobile applications 

Focus Not Obscured

To ensure that sighted keyboard users can see where their current point of focus is, the Focus not obscured criterion is divided into 2 criteria with minimum and enhanced levels. 

2.4.12: Focus Not Obscured (Minimum) (Level AA)

According to WCAG, When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

2.4.13: Focus Not Obscured (Enhanced) (Level AAA)

According to When a user interface component receives keyboard focus, no part of the focus indicator is hidden by author-created content.

The 2.4.12 (Level AA) criteria specifies that at least a portion of the component (and, by extension, its focus indication) is not obscured by other author-created content. Whereas, the 2.4.13 (Level AAA) criterion specifies that the focus indicator component does not have any part of it obscured by other author-related content.

For example, some websites that use sticky headers or footers may sometimes cover the component or element in focus. This may become a problem for users with vision impairments as they may not be able to find the focus indicator on the page. This translates to situations in native mobile applications when the element now in focus is obscured by the top or bottom bar.

Dragging Movements (Level AA)

According to WCAG, the success criterion 2.5.7 states that:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Note:

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

It’s more probable that native mobile apps will make use of drag-and-drop functions than websites.  For example, while making a playlist on Apple Music or Spotify; you can rearrange the songs in the playlist by dragging and dropping them. This kind of interaction calls for highly precise movements and the capacity to keep a finger on the screen without letting go, both of which may be difficult for people with motor impairments. Therefore, this success criterion requires all dragging-based operations to be performed with a single pointer. This translates to situations in native mobile applications where a single pointer can be interpreted as tapping once with a finger.

Consistent Help (Level A)

According to WCAG, the success criterion 3.2.6 states that:

If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content, unless a change is initiated by the user:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

Note:

Access to help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.

If any web pages in a set give assistance (such as contact information or a FAQ section), then all of those pages must include that assistance in the same relative location. This requirement will facilitate the process of customers locating support in times of need. Although web pages are specifically mentioned, this may also translate to screens inside a native mobile app.

Accessible Authentication

To ensure there is an accessible, easy-to-use, and secure method to log in, access content, and undertake tasks, the Accessible Authentication criterion is divided into AA and AAA Levels

3.3.7: Accessible Authentication (Level AA)

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:

  1. Alternative

Another authentication method that does not rely on a cognitive function test.

  1. Mechanism

A mechanism is available to assist the user in completing the cognitive function test.

  1. Object Recognition

The cognitive function test is to recognize objects.

  1. Personal Content

The cognitive function test is to identify non-text content the user provided to the website.

Note:

Objects to recognize and user-provided content may be represented by images, video, or audio.

3.3.8 Accessible Authentication (No Exception) (Level AAA) 

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:

1. Alternative

Another authentication method that does not rely on a cognitive function test.

2. Mechanism

A mechanism is available to assist the user in completing the cognitive function test.

When users need to remember their login and password or transcribe a two-factor authentication (2FA) code from a text message, it may be a hassle to log in to a website or app. To meet these requirements, authentication must be possible without the usage of cognitive tests, or a method must be made available to help users with the tests. Native mobile applications are a perfect fit for this standard. Both Apple’s iOS and Google’s Android offer tools designed to help consumers breeze over these kinds of mental challenges.

By integrating with Apple’s Keychain, an app for iOS may help users avoid having to repeatedly memorize complex passwords. Google’s Messages app for Android has a copy-security-code button in the notification shade for 2FA text messages.

Redundant Entry (Level A)

According to WCAG, the success criterion 3.3.9 states that:

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

  • auto-populated, or
  • available for the user to select.

Except when:

  • re-entering the information is essential,
  • the information is required to ensure the security of the content, or
  • previously entered information is no longer valid.

Entering your delivery and billing addresses separately may be necessary for certain forms. To meet this condition, it is necessary to have tools like the auto population at your disposal to lessen the burden of keying the same thing again and over. Because there is no internet-specific terminology used in the guideline, it is easily adaptable to native mobile apps.

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. We hope that you now have a firm grasp on how WCAG 2.2 may have a significant impact on your native mobile apps. If you need assistance with accessibility services, please get in touch with us at info@aeldata.com.

Aditya Bikkani

Aditya Bikkani

Aditya is the COO of AELData, a growing technology company in the Digital Publishing and Education sectors. He is also an entrepreneur and founder of an accessibility tool called LERA. A W3C COGA (Cognitive and Learning Disabilities Accessibility) Community Member Aditya contributes to researching methodologies to improve web accessibility and usability for people with cognitive and learning disabilities.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share on Social Media

Facebook
Twitter
LinkedIn
Email
Pinterest
Reddit
WhatsApp

Related Blogs

Skip to content