The W in WCAG stands for Web. This makes applying it to Native Mobile environments confusing. If you find yourself in the unfortunate situation of caring about how to apply WCAG 2.2 normatively to Native Mobile Platforms... this article is for you.

Applying WCAG to mobile must be done carefully. I have witnessed many accessibility experts cause frustration and backwards progress for their teams by misapplying WCAG in mobile environments. Here is a breakdown for WCAG 2.2.

WCAG is the sum of its parts. More on this topic to come in future articles!

Applying WCAG 2.2 to Mobile by Success Criteria

WCAG 2.2 Introduces 9 new Success Criteria. These Success Criteria are:

1. 2.4.11 Focus Not Obscured (Minimum) (AA)
   1. Applies: Multiple definitions of input focus to consider.
2. 2.4.12 Focus Not Obscured (Enhanced) (AAA)
   1. Android: Applies directly.
   2. iOS: Applies for Software Keyboard Focus.
3. 2.4.13 Focus Appearance (AAA)
   1. Android: Applies directly.
   2. iOS: Does not apply.
4. 2.5.7 Dragging Movements (AA)
   1. Applies: Translates quite easily!
5. 2.5.8 Target Size (Minimum) (AA)
   1. Ignore: Establishes a barer minimum than set by iOS and Android Platform Accessibility Guidelines.
6. 3.2.6 Consistent Help (A)
   1. Applies: Single App.
   2. Ignore: Across a domain of app offerings. Large effort for negative value.
7. 3.3.7 Redundant Entry (A)
   1. Applies: Support for Operating System auto-fill mechanisms trivializes this requirement, though it is not required for compliance.
8. 3.3.8 Accessible Authentication (Minimum) (AA)
   1. Applies: Support for Operating System auto-fill mechanisms is (should be) required when relying on password manager based solutions.
9. 3.3.9 Accessible Authentication (Enhanced) (AAA)
   1. Applies: Translates easily.

2.4.12 Focus Not Obscured (Enhanced) (AAA)

We're doing these out of order a bit, because the "Enhanced" version of this is actually a lot simpler!

Focus Not Obscured, in the context of a website, refers to the ability for keyboard users to track focus of active elements as they hit Tab / Shift-Tab on the keyboard. The ability to track focus reliably is very important for users confined to keyboard only use. In the case of the "Enhanced" version of this Success Criteria the requirement would be that the entirety of the Focused Element is visible on screen.

2.4.12 Focus Not Obscured - When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

These concepts are not as strictly defined in Mobile Environments. By using the term "keyboard focus" you could be referring to different types of Focus. One definition being the type of events that call the software keyboard in and out of existence. The other being the more generic Input Focus for hardware keyboards and trackballs. The problem with this Success Criteria is the answer is different per platform.

When Applying to Mobile

This success criteria can be applied normatively given the following definitions of Keyboard Focus:

1. Android: We should prefer the broader definition of Input Focus to facilitate both keyboard only use and trackball and joystick navigation, while noting that there are version dependent blockers to true keyboard only navigation.
2. On iOS: We should prefer the more strict definition specifically referring to Text Fields currently accepting text entry.

Hardware keyboard navigation is only supported on iOS through an Assistive Technology called Keyboard Only mode. The iOS Input Focus management system was never designed for hardware keyboard only navigation. While we are certainly concerned with testing this Assistive Technology, they are concerns that are more aligned with managing Accessibility Focus. Associating such issues with this success criteria would lead down a rabbit whole of misleading technical research and wasted time.

2.4.11 Focus Not Obscured (Minimum) (AA)

WCAG likes to do this Enhanced/Minimum thing when there is a set of related criteria that have different conditions and severities.

2.4.11 Focus Not Obscured (Minimum) (AA) - When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

In this case the distinction is:

1. Minimum (AA): Focused element must be partially visible.
2. Enhanced (AAA): Focused element must be completely visible!

The general message between 2.4.12 and 2.4.11 is the same. Refer to the definitions of focus above. Once you apply those definitions the Success Criteria generally makes sense.

However, we virtually never expect these issues to happen. Both iOS and Android do a good job of bringing Focus into view on apps automatically... depending on your definition of focus. In mobile we care about a lot of focus definitions, in this case input focus could refer to:

1. Hardware keyboard focus.
2. Software keyboard focus - tracks with hardware keyboard focus, but also calls up the software keyboard!

Ironically situations you would see the most violations on Mobile is Software Keyboard Focus, however it isn't the one that the success criteria is referring to. This Success Criteria is specifically talking about moving focus around with keyboard only.

Note that a potential interpretation would be that the Software Keyboard is not "author created content". However, I would translate this as meaning content that gets created because of the intent of the author, NOT content that the author specifically designed.

The author in this case should be viewed as requesting the keyboard to appear in the same way that they may request an advertisement to appear. They are clearly responsible for its presence and know where it is located, and should be expected to avoid it.

When Applying to Mobile

Make sure your text entry controls come to rest above the Software Keyboard while text is being entered and the keyboard is attached to the bottom of the screen. The OS should do a reasonable job of doing most of this for you as long as you don't do anything specific to fight it!

The other more generic intent of this applies as well, though I'm not sure failing this Success Criteria is actually possible in cases not outlined above. Would love to see a replicable example of a violation not involving the software keyboard! :)

2.4.13 Focus Appearance (AAA)

Not much to talk about here!

This one is pretty straightforward. Keyboard only/joystick users should be able to navigate their way around your application without losing track of where they are!

While the purpose is straightforward, interpreting it per Operating System is not.

Applying to Android

This success criteria can be applied verbatim to Android. Keyboard only/joystick access without AT has gotten a bump since Compose has become more standard. Though you will still find the occasional keyboard blocker requiring Switch Control in Google applications. Though, with the Android fragmentation problem, this is an issue that will be there forever.

I expect to have to update this translation before WCAG 2.3 comes out. Probably twice :).

Applying to iOS

This Success Criteria should not be applied to iOS. It has no meaning in iOS without Keyboard Only mode on. Keyboard Only mode is an Assistive Technology and is in charge of its own focus appearance and cannot be changed by the content creator.

You could apply a simpler translation of this to the iOS environment by defining Focus in this case to only refer to Text Fields with Input Focus. Though you could not apply it normatively, or would always be blaming any issue on the User Agent... in this case iOS.

2.5.7 Dragging Movements (AA)

There is very little to say here. Very important concept for mobile.

2.5.7 Dragging Movements - 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.

This success criteria reads as if it were written with mobile in mind, no further comment necessary.

2.5.8 Target Size (Minimum) (AA)

This is one of those Success Criteria with a Minimum and Enhanced version. The enhanced version is the original version of this Success Criteria from WCAG 2.1 and has been demoted to AAA.

2.5.8 Target Size Minimum - The size of the target for pointer inputs is at least 24 by 24 CSS pixels... with a list of exceptions that don't apply very often.

In simpler terms make sure your touch targets aren't too small. They're hard to hit!

Applying to Mobile

This success criteria isn't necessary for Mobile. The platform guidelines both advocate for a larger target size and achieving that was already simple enough.

Don't cite this as an excuse to not follow the more strict platform guidelines. Google and Apple know their users well. The W in WCAG stands for Web. Keep this requirement in the realm of mouse pointers the size of a pixel... not fingers.

Android Accessibility Guidance: The two buttons in Counter are small (24dp x 24dp) ... at least 48dp x 48dp.

Google agrees. So does Apple. Their minimum target size recommendations are both north of 40.

3.2.6 - Consistent Help (A)

This one applies completely at face value, but when you dig in deeper it breaks down pretty hard.

3.2.6 Consistent Help - 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 order relative to other page content...

Notice the "web page" and "set of web pages" wording. This Success Criteria is attached at it's core to the way the web is structured and functions. Also, note that websites are much more complicated than mobile apps. I must ask myself if in a Mobile Application Environment this is something that users are concerned about? Curious. Would love feedback on this topic!

Do Apply to Single App

If we define a set of Views to be views within a singular application you can apply this success criteria quite seamlessly and for larger "mega apps" this success criteria would be very meaningful.

Don't Apply Across Separate Apps

In some of the extended material and definitions for this success criteria you come across this definition for a "set of pages":

a blog on a sub-domain (e.g. blog.example.com) which has a different navigation and is authored by a distinct set of people from the pages on the primary domain (example.com).

This would roughly translate to separate application packages owned by the same organization. So for example:

• com.google.chrome
• com.google.messages
• com.google.drive
• com.google.docs
• com.google.slides
• com.google.youtube
• com.google.......

This success criteria absolutely should not apply in those situations. Those applications rightly have their own experiences. Google Drive and YouTube should be expected to have help content that suits the users of those applications and for it to be placed wherever feels natural for those experiences, regardless of what the delivery mechanism is.

Subdomains on web have tighter relationships to their corresponding web content. Attempting to achieve this level of consistency across the entirety of a set of application offerings would be heavy lift for something that may actually detract from the value being delivered.

3.3.7 - Redundant Entry (A)

Redundant Entry is meant to ensure that users can get through a process without repeatedly entering information. This concept is extra important in a Mobile Context where users time is limited and distractions often occur! Getting users through processes quickly is what Mobile Application user experience is about.

3.3.7 Redundant Entry - 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.

While technically not a requirement of the Success Criteria, the reference to the Auto Population of data is most easily achieved by leveraging the Operating Systems mechanisms designed for doing so. These exist in both iOS and Android and facilitate both the platforms auto-fill mechanism and serve as the backbone for third party auto-fill software.

Not only does this Success Criteria translate to mobile well, iOS and Android both have existing mechanisms to support the auto fill portion of this out of the box!

3.3.8 - Accessible Authentication

The enhanced version of this criteria has no mobile specific concerns and can be applied directly. The minimum version of this criteria follows:

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 the Web site.

In a nutshell make it easy for users to sign in to your apps. Don't force them to remember things, even passwords.

Applying To Mobile

This quite clearly applies to Mobile Ecosystem. The inclusion of passwords and password managers means support for the Operating Systems mechanisms for identifying input fields. Whether or not rolling your own solution for that would satisfy this criteria is questionable, but please don't. Just don't. Support the OS features for this! It's the only thing that makes sense.

The absolute simplest way to satisfy this success criteria is to support single sign on with the account the user signs onto their device with. If this isn't feasible, this success criteria outlines a solid minimum expectation, with a lot of platform specific solutions that are quite compatible!