Web content accessibility guidelines for mobile

This is an excerpt from my recent APress Book Developing Inclusive Mobile Apps: Building Accessible Apps for iOS and Android.

With a name like Web Content Accessibility Guidelines, it can be tempting to write these off as not applicable to mobile. The name, however, is a function of the era the guidelines were authored throughout. The Web Content Accessibility Guidelines were written in the 1990s and 2000s, with the last major update coming in 2008, a time before mobile enjoyed the ubiquity it does today. WCAG, an ISO standard since 2012, forms the basis of many accessibility laws throughout the world. It is often used as the benchmark for courts to decide if a digital experience is accessible or otherwise for the sake of accessibility lawsuits. As such, so far as the law is concerned, WCAG very much applies to mobile.

W3C has split the WCAG into four layers beginning with four overarching principles – perceivable, operable, understandable, and robust. In this post we will cover the first principle - perceivable.

Information and user interface components must be present- able to users in ways they can perceive.

—WCAG 2.1

The first principle, perceivable, covers the content in your application and ways in which you make that available to your customer. To summarize this principle in a word, I would use “alternatives.”

The telephone, as initially designed, uses just one medium, audio. While this will cover the majority of use cases, it immediately rules out people who struggle to speak and people who struggle to hear. The invention of the Telecommunications Device for the Deaf was a necessary alternative to allow people in that situation to have the same experience as the rest of us. In the same vein, if you provide content in a visual-only format such as images, text that is not available to the screen reader, or a captioned video without an audio track, your customers with visual impairments will not be able to access this content.

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

—WCAG 2.1

Ensure that all non-text content has an appropriate and equivalent text alternative. Often this applies to meaningful images. The distinction between content and noncontent is essential here. Providing a descriptive accessible label to decorative images can give a richer experience for your users. But be careful not to distract from your app’s content.

The ability to add a text alternative to almost any object is baked into both major mobile platforms. Android uses the contentDescription property. In iOS, accessibilityLabel will achieve the same. See examples of both below

Setting an Android contentDescription in a layout XML file:  

Setting an Android contentDescription in code:

Setting an accessibility label in iOS:

Provide alternatives for time-based media.

—WCAG 2.1

To you and I, this means audio and video. Additionally, it covers any media that has a time component to it such as animation. Video and audio should feature captions or a transcription. Preferably video should include audio description, and ideally both audio and video should incorporate or have an option for sign language.

This guideline excludes video or audio you provide as an alternative to text. If you do provide these as an alternative, be sure to mark them as such. If you don’t make it evident to your users that your media is an alternative, people who can’t use this may feel excluded.

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

—WCAG 2.1

The adaptable guideline moves away from the content and covers how you present the content in your UI.

Present content in a clear, meaningful order. You can achieve this through good interface design, but take care to test with screen readers enabled. These can often navigate your screen in ways that might not be natural to sighted users. For example, consider a screen with a large hero image followed by a title. Your eye would usually skim the image and be drawn to the title. A screen reader will focus on the alt text given to your image first unless you specify that the title should be the initially focused item.

Present information in multiple sensory characteristics. Don’t rely on color alone, for example, but a combination of attributes such as color, shape, size, location, or sound. You can use any or all of these modes together to infer meaning.

Input fields and other controls should identify the purpose or action for that control. Use the contentDescription property on Android and accessibilityLabel property on iOS to achieve this. On iOS, accessibility traits are a powerful tool to inform assistive technology, and its users, about how a control will function. An accessibilityHint on iOS or hint on Android can give extra context if needed.                    

Setting a hint in an Android layout XML file:

Setting an accessibility hint in UIKit:

Make it easier for users to see and hear content including separating foreground from background.                

—WCAG 2.1

The distinguishable guideline covers how your users tell the difference between elements in your app. This guideline includes essential rules for contrast, text size and line spacing, background audio, and others. Some disabilities such as color blindness might impede our ability to distinguish between elements. So sticking to these guides and allowing customizability, where needed, are essential. Unless your layout demands it, avoid scrolling in two dimensions as this can be a trigger for people sensitive to movement. It can also be challenging to control with some assistive technologies enabled.                                              

This guideline also provides advice on the following elements.                                           

Color

Your use of color in any app is crucial. The right choice of palette can be a significant factor in setting your app apart. Well-used color can be a subtle hint at meaning and aid understanding. Remember, however, that not everyone’s experience of color is the same; therefore, the color should never be the only way to identify elements or convey meaning. Combine coloring with text, shapes, or animation. Yellow warning triangles, for example, are not just called “yellow warnings” – the triangle part is essential to its utility.

The contrast ratio between your text color and the text’s background color are a material consideration. Large text – defined as a minimum of 18pt, or 14pt bold – should have a minimum contrast ratio of 3:1. Smaller text should have a contrast ratio of 4.5:1. Ideally, your text should have a contrast ratio of 7:1, with larger text at 4.5:1.

Some people, such as those experiencing dyslexia, Irlen syndrome, or color blindness, can benefit from the ability to customize background colors. This would be a great addition to your app if you’re looking to take your accessibility to the next level.                            

Audio                   

Any audio in your app - including audio as part of video - lasting longer than 3 seconds should have controls. These should allow for pausing, stopping, and adjusting the volume. The volume control should be independent of the system control to let your customer maintain their chosen system level.

Any speech audio should avoid background sounds. Alternatively, allow the disabling of background sounds or have background sounds a minimum of 20db (at least four times) quieter than the speech audio. Background noise can affect those with attention disorders; it can also make the foreground audio challenging to determine for some people with hearing impairments if their hearing is distorted.

Text

Text should be resizable up to double the glyph size without losing content or functionality. Ensuring your support system, dynamic text sizes on both platforms will fulfil this requirement. Avoid using images of text as these don’t support screen readers or text size adjustments. If you must use an image containing text, ensure you add a screen reader-accessible label including the text to the image. Do this using the contentDescription property on Android or accessibilityLabel on iOS.

When formatting text, aim for the following: avoid full justification, keep lines of text to a maximum of 80 characters, and provide paragraph spacing of 1.5 times the line spacing. Let your users customize to their needs by providing a mechanism to change text and background colors.

***

WCAG covers a wide range of affordances that you should consider in our mobile apps to ensure all of your customers get the best user experience. Here we covered just one of the four principles of WCAG. Understanding the remaining principles of operable, understandable, and robust is important to building accessible iOS and Android apps.

People photo created by MontriThipsorn - www.freepik.com