The fate of 'Target Size'

1. February 2018

The last draft of the WCAG 2.1 contained a new Success Criterion Target Size (size of buttons, form controls or links), which is now missing in the Candidate Recommendation of WCAG 2.1. Why has it not made it into the revised standard?

In the now published WCAG 2.1 Candidate Recommendation, the hotly-contested Target Size requirement is only included at the AAA compliance level, which means that for the time being there will be no mandatory legal requirement for target size with reference to the European Standard EN 301 549.

The last WCAG 2.1 working draft said:

"Success Criterion 2.5.3 Target Size

Level AA

The size of the target for pointer inputs is at least 44 by 22 CSS pixels"

This was followed by several exceptions for inline targets like text links, and hard-to-style native HTML elements such as checkboxes, radio buttons or selects.

In addressing several public comments, the Accessibility Guidelines Working Group struggled to agree on a specific size.

Target size for mouse input and touch input

A fundamental problem was to distinguish between the mouse input with the finer cursor and the touch input (which requires larger targets, because the 'fat finger' obscures the view). Hybrid devices often allow both types of input. Also, there are more and more device types which fall inbetween the desktop world and that of "mobile devices" – take, for example, the iPad pro.

Advantages and disadvantages of large targets

The basic advantages of large targets are clear from the perspective of users with motor impairments, but also from the perspective of low vision users. On the other hand, larger targets also have disadvantages: using them means desginers can put significantly less content into the visible section of the screen. So users need to scroll, or web designers need to split content into more views or 'hide' part of the navigation or IDE controls in drop-downs or menus. That, in turn, has usability disadvantages. The affordance of the "overall view" - the quick overview of content - suffers.

The search for solid ground

Another difficulty was determining a particular size. Google recommends 48 x 48 CSS pixels in the Material Design Accessibility Guidelines, Apple has 44 x 44px  in the Human Interface Guidelines for iOS. The user studies that existed, however, assumed a need for 100 x 100 CSS pixels, a requirement that would be difficult to meet for most sites without significant changes.

New barriers through big targets?

But even a target size requirement of 44 x 44 CSS pixels is not easy to meet, even when it excludes inline targets such as text links. For the popular drop-down navigation menus, it would significantly reduce the number of submenu items that are still visible on the viewport without scrolling. And if you wanted to scroll there, the menu would typically close. For visually impaired users who work with magnification software, the problem is exacerbated. Thus, larger targets also potentially create new barriers. To avoide these, designers would often need to reduce the number of menu items, which has a significant impact on the content structure).

No agreement - so far

The compromise proposal of a size of 44 x 22 CSS pixels, which would have allowed a lower height for things like dropdowen menus, was always controversial in the Working Group. This value no precedent in OS guidelines or other recommendations and no empirical backing in user studies - it was simply a compromise, born of necessity. Other last-ditch approaches attempted to specify the 44 pixels on one dimension of the target and to define the other dimension via some other measure like the height of the standard text size.

Ultimately the Working Group found no majority for any of the proposed wordings for target size at conformity level AA, so the Success Crtierion was dropped. The topic will certainly be taken up again in the development of the next WCAG version (be it WCAG 2.2 or the complete overhaul with the working title Silver).