Identify Input Purpose (WCAG 1.3.5) on mobile applications

(Read 320 times)

Autocomplete and correct keyboard layout when filling out forms are simple and powerful helpers to make less errors when filling out forms. They benefit everybody, but they are even more appreciated by people with different disabilities. Web support is there for years, but what about native mobile applications?

When auditing mobile applications for Web Content Accessibility Guidelines (WCAG) 2.1 conformance (or for EN 301 549) I often wondered what can be done while evaluating WCAG success criterion 1.3.5 – Identify Input Purpose (opens in new window). The guidelines are very clear when we consider web:

The purpose of each input field collecting information about the user can be programmatically determined when:

  • The input field serves a purpose identified in the Input Purposes for user interface components section; and
  • The content is implemented using technologies with support for identifying the expected meaning for form input data.

But what about native mobile applications? Not so clear.

When I audit native mobile applications I always check the official sources first. WCAG is pretty active on GitHub (opens in new window), but some issues sometimes make things even less clear or are even outdated. An example related to 1.3.5 is Applicability/testability of 1.3.5 for native apps (opens in new window), that offered useful tips but no clear answers. After investigating some more I decided to reach out to official Android and iOS documentation, as I am not a native app developer and I think it’s crucial to know the technical capabilities for native mobile apps before we can establish if WCAG success criteria is accessibility supported or not.

Short answer – 1.3.5 is applicable for mobile applications, but

I often feel that it’s way simpler with the web. I know the technology, it’s cross-platform for most of things and I have good overview. With native mobile app development I need to dig into technical possibilities before establishing how WCAG can be applied. It’s not strange when we consider differences between platforms and also differences between versions on same platforms. Then we also need to consider native frameworks that are used and on the end also all third party libraries and frameworks that enable unified development via single codebase. So it’s not strange that it’s way more complex than the web.

Both Android and iOS, in their latest versions and on their native frameworks, offer pretty decent support for field semantics and also for autofill (or call it autocomplete if you want). So I think we should mark applications that don’t apply these technologies failing WCAG 1.3.5. Because possibilities are there. The problem is, as mentioned before, which version we are on. So if the latest few versions support field semantics and autofill, should we always consider elder versions and explain that 1.3.5 is not applicable because it’s not supported in the old version?

I don’t think so. I think we need to promote the capabilities of the more modern frameworks that support 1.3.5 but also be clear that older versions may not support it.

Android has optimizeForAutoFill and inputType properties

Most phones and tablets running Android 8.0 (API level 26) and higher ship with an autofill service, so there are less and less excuses not to implement this. Official docs for Optimize your app for autofill (opens in new window) will provide you with the details and I always refer to them when auditing Android apps.

There are possibilities for name, emailAddress, phone, postalAddress, postalCode and so on. Even creditCardNumber and creditCardExpirationDay and so on.

Setting keyboard types is also supported like for example textPersonName, textEmailAddress and so on.

Please check the docs and start using it if you haven’t yet.

iOS has textContentType and keyboardType properties

Official iOS UIKit docs for textContentType (opens in new window) will provide some initial information so that you can start using it in your code.

To support different keyboards you need to use proper UITextContentTypes (opens in new window) as far as I could establish.

Apple produced a video called AutoFill everywhere (opens in new window) that explains some more details and I encourage you to see it (or read the transcript).

Conclusion – 1.3.5 on mobile is possible so please enable it

Everybody hates forms, at least so it seems. And everybody hates forms even more when they don’t support autofill / autocomplete, so please make forms simpler for everybody.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: