WCAG 2.1: The Area Of Effect For Mobile Accessibility

By Helen Burge

Accessibility guidelines are not a recent trend, but with events in the Digital World, they are taking more prominent roles within companies. Whether due to the Winn-Dixie case in 2017 where an American judge ruled the ecommerce site should meet Web Content Accessibility Guidelines (WCAG) 2.0, or the momentous Target trial resulting in a $6 million ruling in 2006.  While the guidelines for accessibility have been around for over 20 years only recently have more companies felt the legal implications of accessibility requirements.

In 1994, the 2nd International Conference on the World-Wide Web in Chicago inspired the first published guidelines by Gregg Vanderheiden in 1995.  Since then 38 different sets of guidelines were authored over the following two years. They were brought into a collaboration with the Unified Website Accessibility Guidelines in 1998. WCAG 1.0 was published and became a W3C recommendation on 5 May 1999.

WCAG 1.0 consist of 14 guidelines. The guidelines were based on previous findings and offered guidance on how to make web content accessible to all. When they were released, the guidelines were deemed too basic or subjective to accurately build accessible websites.  Due to this the WCAG Samurai, a group of developers independent of the W3C, and led by Joe Clark, published corrections for, and extensions to, the WCAG 1.0 in early 2008.  

The W3C also noted the limitations of WCAG 1.0 and released WCAG 2.0 at the end of 2008 after starting the process in 2001. The 14 original guidelines were reduced to 12 with four guiding principles where websites must be perceivable, operable, understandable, and robust.

The release date of 2008 was ironic due to the fact the first mobile smartphone was released with assistive technology in 2009 by Apple. This meant WCAG 2.0 was written with little mobile or tablet focus, and in the last 5 years, mobile applications and responsive websites were required to be accessible but there was little official guidance.  

The W3C did release an article mapping WCAG 2.0 to mobiles in 2015, with recommendations rather than an official stance. This working group highlighted a need to update WCAG 2.0, so in 2016, WCAG 2.1 was officially started with the request for feedback on the editors’ draft. This long-awaited set of guidelines are due to be released in June of 2018.

How Will WCAG 2.1 Impact Users?

The main users to benefit from the adoption of WCAG 2.1 guidelines are those relying on assistive technology with a mobile device, users with limited vision, and users with cognitive issues.   Eleven of the revised checkpoints will focus on those who may have memory, short attention spans, or problem-solving limitations. For limited vision users, the colour ratio checkpoint was written with the desktop monitor in mind, and for text only.  New checkpoints like 1.4.11 create guidelines for image ratios which handle situations when an icon is used for a button, like a play button, the icon should have a strong contrast from the background colour of the button.

What Software Testers Need To Know About WCAG 2.1

Testers might see the increase of checkpoints as more work.  Normal audits will cover the level A and AA checkpoints which are the minimum legal requirements. Additionally, there are AAA checkpoints but these are a nice-to-have category.  In WCAG 2.0 there are 38 level A and AA checkpoints, but in WCAG 2.1 there are 50 checkpoints across both categories.  

Semantics Vs User Types

Ideally, people testing a website or a mobile application are not trying to tick off a list of checks.  A good functional tester never sticks only to what should happen, but what each user type is likely to try when using the site under test. The same should apply to accessibility testing. The semantics of a page can pass the checkpoints, but if you do not validate a page with the different user types that rely on assistive technology, or may have difficulties, then you are missing a lot of opportunities for possible improvements for your users.  

Emulating User Needs

When you approach testing for an accessibility user type, it is about emulating the needs of the different users.  

A screen reader user is likely to have little or no eyesight.  You’ll want to use the recommended keyboard navigation on the desktop, and user gestures on a mobile device. Another option for mobile users is a Bluetooth keyboard. There are a few main user types, those that rely on a screen reader, as have little or no vision; keyboard only users that due to different limitations cannot use a mouse or touch screen easily; low or poor vision users that may need to zoom or use glasses; mobile only users can cover all types of users but using a smartphone instead of a desktop device; cognitively challenged users that require more simple and easy to follow workflows.  Here are the new WCAG 2.1 A and AA checkpoints that apply to each user type:

The extra checkpoints are good for testers as more credence to items deemed a failure but would be lumped in 1.3.3 (as relying on one sense to understand the context of items).  The recommended approach to auditing is to emulate different user types, but doing this also means it is important to have a team validating the pages. Trying to cover so many user types is difficult for one person.  The extra checkpoints should help lone testers not miss the other user difficulties that might have been missed before.

WCAG 2.1 Checkpoints

Same Old Checkpoints

The reason why this update is not a new number, e.g. WCAG 3.0 is that WCAG 2.0 checkpoints all remain in the update. This makes sense because the guidance and techniques listed have been around for less than a decade. The guide is updated on an annual basis to keep up-to-date with the latest technologies.  Most of the WCAG 2.0 checkpoints are the same and new checkpoints are amended in after the existing checkpoints to be backward compatible. WCAG 3.0 will restructure the guidelines but does not have an official timeline yet.

Shiny New Checkpoints

The new checkpoints being added are as follows:

Guideline 1.3 Adaptable

1.3.4 Orientation - AA Checkpoint

If a user wants a monitor or device to be landscape, the content displays in the same readable way as if the orientation is portrait.  This does not apply if the orientation affects the performance or operability of the application, like a video.

1.3.5 Identify Input Purpose - AA Checkpoint

This expands on the WCAG 2.0 level A checkpoint 4.1.2.  Customization of icons, fields or buttons are important to cognitively challenged users.  This allows the user to use saved autocomplete for form fields when the assigned labels match the saved associated labels. For customising the icons, often on smaller screens, a lot of buttons are replaced with image icons, and what is intuitive to one user is not for another.  By conforming to a standard, this will allow a user to be able to specify their own icons and meanings to minimize confusion. The customisation can be achieved by a third-party tool, like a browser add-on. This checkpoint will also help users that prefer to use the keyboard with the ability to assign shortcuts to the buttons.  

1.3.6 Identify Purpose - AAA Checkpoint

Adding to the AA checkpoint 1.3.5, this allows for customization using a globally recognized language.

Guideline 1.4 Distinguishable

1.4.10 Reflow - AA Checkpoint

Guidelines are suggested for simple content like text, and screens zoomed to 400 percent which could need two-directional scrolling.  Images, videos, and data tables, are considered out-of-scope for this checkpoint. When the screen is zoomed in, text is expected to wrap to new lines so the user only requires one scroll direction to read the content. This checkpoint is important for limited vision users and mobile users.

1.4.11 Non-Text Contrast - AA Checkpoint

This checkpoint might be removed from the final draft.  Updates for colour contrast include visual items that are required to be seen to understand the context.  For instance, video controls needed to stop or start content will need a ratio of 3:1. This is a difficult checkpoint to test because it is based on context. What might be required to one user may not be for another, and therefore would need to be tested on a case-by-case basis.

1.4.12 Text Spacing - AA Checkpoint

Giving a limited vision or cognitively challenged user the ability to change the spacing and making sure the content is still readable informs this guideline. Challenges to developing and testing this kind of flexible content could be around making sure the various pieces of content do not overlap or cause odd layout issues.

1.4.13 Content on Hover or Focus - AA Checkpoint

The definition of “focus” based on accessibility terms means the user can navigate the item unless controlled by the application. Allowing a component which is given focus, to be closed by a keyboard or mouse is important for users with poor eyesight who may need to increase text size or mouse size. This allows the user to keep a tooltip open and move the mouse around it,  without it closing. Users with cognitive challenges or physical challenges will see benefits from this guideline as sometimes a short display time is not enough to read a tooltip or pop-up. This is similar to the keyboard checkpoints in 2.1 but includes the mouse and a few user types not previously covered.

Guideline 2.1 Keyboard Accessible

2.1.4 Character Key Shortcuts - A Checkpoint

Single key shortcuts, when implemented, should have a way to amend or disable them. These shortcuts can interfere with speech recognition software, cause difficulties for keyboard only users, or users with motion difficulties that could activate the keys without meaning to.

Guideline 2.2 Enough Time

2.2.6 Timeouts - AAA Checkpoint

Data loss warnings are important to the user. This checkpoint extends the 2.2.1 checkpoint around data handling.  In some cases, if a user has entered data in a form, and not signed in such as a purchasing workflow, the session times out and the user loses all entered data.

Guideline 2.3 Seizures and Physical Reactions

2.3.3 Animation from Interactions - AAA Checkpoint

This checkpoint that might be removed in the final draft. If interactions have animations, the user should be able to stop it unless it is essential to the application process.

Guideline 2.5 Input Modalities

2.5.1 Pointer Gestures - A Checkpoint

The use of single-point activation, not including gestures required to operate assistive technology,  should help users with cognitive issues, or people not able to perform complicated activations. The simpler an interface, the easier for the majority to use. When a graphic requires a slider zoom action, it can be complemented with keyboard interaction with the + or – buttons.

2.5.2 Pointer Cancellation - A Checkpoint

Users with visual, motor, and/or cognitive challenges have issues with accidental activation of features. Users should be able to reverse accidental activation of a feature and recover from it if necessary.  This applies to most transactions but not when the timing is important, like an action game.

2.5.3 Label in Name - A Checkpoint

Users that rely on speech input need labels for user interface components. For someone using a voice command tool, the named fields should match the labels the voice command tool will reference.  It also helps users with cognitive challenges that rely on speech input reducing the cognitive load for remembering item names.

2.5.4 Motion Actuation - A Checkpoint

Navigating web content on a mobile phone can be hard for average users. Using the device to change content with a tilt motion gives the user more ways to control content, along with having next and previous page buttons available.  

2.5.5 Target Size - AAA Checkpoint

If there are activation items on a screen, this checkpoint requires the activation area is 44 x 44 CSS pixels.  If there are multiple items that can perform the same action, then only one must meet this criterion. Users who have issues with fine motor movements should benefit from this guideline.

2.5.6 Concurrent Input Mechanisms - AAA Checkpoint

This checkpoint to allow more than one input type in the web content like entering data in a form field.  Therefore, a user can use the keyboard or mouse on any device even if the main input device might be touchscreen.  If the form field only allows for a mouse to activate it (like opening a select list) then this fails this checkpoint.

Guideline 4.1 Compatible

4.1.3 Status Messages - AA Checkpoint

This checkpoint is for low vision or blind users. It is to notify or allow a user that may not see the updates of items to be notified.  If you’ve selected an item to buy, but after selecting a specific colour, and the size is no longer in stock, then a notification of the change is heard by the assistive technology and reported to the user. When searching for items and results are returned, without moving the focus, the user should hear the results returned from their screen reader application.

WCAG 2.1  Going Forward

Most testers that have done accessibility work will note most of the new checkpoints enhance work already done when testing websites for compliance. There are a few more checks required that were not necessary before, like changing your preferences to check the spacing is possible as recommended.  

Overall, the updates are good for providing more structure and compliance techniques for what were grey areas before in 2.0.  In some cases, companies would ignore items hindering some users as not outlined as a “must have” in the checkpoints or required for legal compliance.  Going forward, these updates will help more users, and by meeting WCAG 2.1 most users will appreciate the updates as an accessible site is a more user-friendly site.

Keep up-to-date by following recognised experts who are on the panel of authors for the WCAG 2.1 checklist.  Most of these experts have blogs or articles hosted by their employers. These materials can be great references and some of the authors also provide training.

Author Bio:

Helen Burge has a Business Information Technology degree from Bournemouth University and graduated in 2003.  After leaving university she worked in testing and part of all her roles involved accessibility testing due to her fascination at how unappreciated the need is to make websites and applications accessible.  Helen worked closely with developers to help learn the most effective way to find and report issues. From this, she built a unique test methodology to make sure accessibility bugs are not subjective but make sure any issues raised are reproducible with actionable items.  This approach has ensured the development team can resolve issues and understand the impact on the end users.