The right swipe: 3 things you need to know about upcoming changes to mobile web accessibility guidelines (WCAG 2.1)

In June 2018 the final draft of World Wide Web Consortium's WCAG 2.1 (Web Content Accessibility Guidelines) will be released. AbilityNet accessibility and usability consultant Alladin Elteira offers some important information about the guidelines ahead of their launch in our latest webinar. 



Alladin writes:

WCAG 2.1 will use the same conformance model as WCAG 2.0 with some additions intended to address accessibility gaps. One of the three main points it is intended to address is the accessibility needs related to mobile, since back in 2008 when WCAG 2.0 came out mobiles were not as advanced as today. Our three points below are all basic recommendations - Level A. The government's accessibility standard, which organisations should ideally look to meet under the Equality Act 2010, is the higher Level AA.

The three main success criteria recommended for mobile accessibility under WCAG 2.1

Pointer Gestures (Level A): Avoid two-finger pinch zoom, swiping and dragging.

The use of complicated and complex gestures is discouraged, this also includes path-based gestures. This is because not all users are capable of performing them, nor have the dexterity accuracy needed - Tinder, we're looking at you! An example of such gestures would be two-finger pinch zoom, and path-based gestures like swiping and dragging.

A woman using Tinder with option to swipe right or left

As an author your responsibility lies in providing an alternative to these complex gestures, to ensure that users are able to perform the action with single-point activation. Examples of single-point activation methods would be tapping, double tapping, or long press.

It’s worth noting that this success criterion will often not only benefit users with dexterity limitations, but all users and users with cognitive impairments in particular, as they might not be aware of these complex gestures.

Motion Actuation (Level A): Limit shaking and tilting requirements

This success criteria ensures that users are not forced to rely on motion alone to activate or trigger a functionality. Its intent is to help users with motor impairments who for instance might have limited movements and be unable to shake or tilt the device to activate the camera or activate sensors to pick up their movement, as is sometimes required. We can also look at examples of some people with autism who might move their hands a lot/ quite fast. This could activate a flashlight on the phone example, without intention. 

Alternative user interfaces should be provided, unless the motion is absolutely necessary for the functionality, for example counting steps on an activity tracker.

An example of such solutions would be providing ‘Next’ and ‘previous’ buttons to navigate between pages, instead of only counting on tilting the device, as some smartphones currently do.

Orientation (Level A)

Both portrait and landscape orientations should be supported. Locking the orientation to only one of them means a failure against this success criteria as some people might find it easier to view or hold the screen in one particular way, or for example, might have their device attached to the arm of a wheelchair and not be able to easily re-angle their screen. 

In addition, if a screen reader user is unaware that the orientation has changed, the user might perform incorrect navigation commands. Therefore, mobile application developers should try to support both orientations.

WCAG 2.1 also addresses accessibility issues related to low vision and cognitive impairments, with additional success criteria, all as usual falling under three levels of conformance A, AA, and AAA.

For more details on the remaining WCAG 2.1 Candidate Recommendation, see here.