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).



Comment by Patrick H. Lauke |

For me, the main stumbling block was that at its core having large target sizes leans more towards a usability affordance rather than a pure accessibility one. Particularly considering that (for web content at least, leaving out native applications) there's almost always a way for a user to zoom and make targets bigger.

Additionally, WCAG's need for testability didn't allow for a qualifying clause such as "the most important targets", for instance. Even the guidelines from Google, Microsoft, Apple only strongly suggest, rather than mandate, minimum touch target sizes - and all three companies regularly break their own guidelines (the classic example being the "Back" control that appears in iOS' title bar when doing things like opening a web link in

The proposal to qualify the SC with something like "a mechanism is available" would have, in my mind, helped salvage some of this even for AA. But alas, it is what it is...

Comment by Stomme poes |

A minimum gap between clickables was also missing everywhere-- I've only seen those in Microsoft's guidelines (a 2mm minimum).
Even having a minimum size at AA for *some* things would have been nice-- I consistently cannot, for example, click numbers of pages in a pagination sequence (certainly not accurately), nor the tiny dots of a carousel (used on some e-commerce pages to view multiple images of a product). As a user I find more problems with things where finding more room is a non-issue or just not being stupid with the design than with all the other things mentioned that would cause trouble at a AA level. Maybe a more restricted list of things would have gotten through at AA.

Yet another reason to have a WCUG to poke websites with.

Reply by Detlev Fischer (INCOBS)

@Stomme poes: There actually was an eleventh-hour attempt to add (possibly dated) Microsoft requirements that specified a minimum distance between targets, but it was getting too convoluted by far. Distance is an issue and needs to be taken into account in the next stab...

Comment by Patrick H. Lauke |

"Even having a minimum size at AA for *some* things would have been nice" the problem has always been being able to normatively and unambiguously define this "some". There were many attempts to somehow normatively define exclusions/exceptions, and that bumped against the same kind of problem in reverse. This is certainly one of the biggest problems of the way SCs need to be worded - you can't use vagueness, otherwise it's not unambiguously understandable/testable.

Comment by Stomme Poes |

Okay, w00ts, I got it: AA == "pagination and stupid carousel dots."

Comment by JF |

@Stomme poes - Or perhaps you want to jump in and help refine the SC to eliminate "pagination and stupid carousel dots" while not breaking other requirements? Threading this needle is hard - standing on the sidelines booing doesn't help move the ball forward. :)

Comment by Patrick Lauke |

@JF I've been standing right on the playing field booing AND trying to help thread the needle... and yet here we are, with an SC that now cannot be refined further as it's going to be immutable (assuming future work on 2.2 will follow the same "can't touch any of the existing wording, only add, never replace/modify" work mode).

Write a comment