Current versions of SC and Definitions

• AA SC for viewing | AA SC for editing
• AAA SC for viewing | AAA SC for editing
• Target definition for viewing | Target definition for editing
• SC in full draft guideline

Open issues and Surveys

Open issues: SC Status page

• May 16 2017 Survey
  (Links to surveys require W3C Member access)

SC Shortname

Target Size

SC Text

LEVEL AA
The size of the target is at least 44 by 44 CSS pixels for pointer inputs except for the following:

• Customizable: A mechanism is available to change the size of the target independent of the level of page magnification.
• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels.
• Essential: A particular presentation of target is essential to the information being conveyed.
• In-Page: The target is a text link where the destination is on the same page.
• Inline: The target is in a block of text.
• User agent control: the appearance of the target is determined by the user agent and is not modified by the author.

LEVEL AAA
The size of the target is at least 44 by 44 CSS pixels for pointer inputs.

Related Glossary additions or changes

Target: Target: Region of the display that will accept a touch action. If a portion of a touch target that does not perform the same action or go to the same page is overlapped by another touch target such that it cannot receive touch actions, then that portion is not considered a touch target for purposes of touch target measurements.

Pointer inputs: input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact. (modified slightly from https://w3c.github.io/pointerevents/#glossary)

CSS Pixel: https://www.w3.org/TR/CSS2/

What Principle and Guideline the SC falls within.

New Proposed Guideline "Pointer Accessible"

Make it easier for users to operate pointer functionality.

Editorial Note for WCAG group: Pointer includes "Touch" in its definition

Description

The intent of this success criterion is to help users who may have trouble activating a small target because of hand tremors, limited dexterity or other reasons. If the target is too small, it may be difficult to aim at the target. Mice and similar pointing devices can be hard to use for these users, and a larger target will help them greatly in having positive outcomes on the web page.

Touch is particularly problematic as it is an input mechanism with coarse precision. Users lack the same level of fine control as on inputs such as a mouse or stylus. A finger is larger than a mouse pointer, and generally obstructs the user's view of the precise location on the screen that is being touched/activated.

The issue can be further complicated on for responsive/mobile which need to accommodate different types of fine and coarse inputs (e.g. a site that can be accessed both on a traditional desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen).

While this criterion defines a minimum target size, it is recommended that larger sizes are used to reduce the possibility of unintentional actions. This is particularly relevant if any of the following are true:

• the control is used frequently;
• the result of the interaction cannot be easily undone;
• the control is positioned where it will be difficult to reach, or is near the edge of the screen;
• the control is part of a sequential task.

Examples of Success Criterion

• Three buttons are on-screen and the visible portion of each button is 44px by 44px
• Button on the screen is defined at 44px by 44px with the viewport width is set to device-width

Working Group Notes

To be added to understanding/techniques documentation related to this SC.

"How can authors determine if they need to follow the guidance for fine or coarse pointer?"

• seeing that it's not possible to reliably detect a touchscreen, and - particularly in multi-input scenarios - it's not easy to know for sure even if a touchscreen can be detected whether or not a user will actually use that or some other input device instead: unless you are designing/developing for a closed system where you know for a fact which type of input(s) will be available (e.g. embedded system only to be used for touchscreen-enabled point of sales terminals, or a system for content only to be used on an ATM style device without touchscreen but with physical keyboard-like buttons on the side of the display), developers should assume that at some point or other their content/app will be used on a touchscreen; see also "when any [...] machine could have a touch interface, [...] proceed as if they all do" https://medium.com/let-me-repost-that-for-you-zeldman/jason-grigsby-on-design-beyond-touch-e862b699d426#.9go7knctr

• offer the user a mechanism as part of the app/site UI to switch between "mouse-friendly" and "touch-friendly" interface. this is the approach that, for instance, Microsoft Office 2013 uses (See slide 137 https://patrickhlauke.github.io/getting-touchy-presentation/#137)

• use CSS Media Queries Level 4's "any-pointer" feature to ascertain if a coarse pointer is present (indicating at least one of the inputs available to the user is coarse, e.g. a touchscreen) https://drafts.csswg.org/mediaqueries-4/ (note my article on using CSS MQ4 detection carefully https://dev.opera.com/articles/media-features/, as well as recent discussion on changing the spec to drop the idea of "primary" vs "rare" inputs [mediaqueries-4] Interaction Media Features make a rigid primary/"rare" distinction csswg-drafts#690)

• use third-party libraries like https://github.com/ten1seven/what-input to detect as soon as a user switches between using a mouse/touchscreen - then it's up to the app/site to decide what to do (immediately switch out the interface to coarse or fine pointer optimized? present the user with a dialog asking if they now want to switch to the type of input that they just used? etc)

Benefits

• Users who use a mobile device where touch screen is the primary mode of interaction
• Users with mobility impairments, such as hand tremors
• Users who find fine motor movements difficult
• Users who access a device using one hand
• Users with large fingers, or who are operating the device with only a part of their finger or knuckle
• Users who have low vision may better see the target

Evidence

• Apple touch target size recommendations (44 points X 44 points) (note that Apple's "points" is a density-independent unit of measure unique to Apple - not related to CSS pt nor real-world physical points as measured in traditional print; 1 point = 1 CSS px - see explanation https://ivomynttinen.com/blog/ios-design-guidelines)
• Android touch target size recommendations (48 CSS pixels X 48 CSS pixels) (note that Google generally use "dp" - density-independent pixels - as unit of measure https://material.google.com/layout/units-measurements.html#units-measurements-density-independent-pixels-dp - but as noted "When writing CSS, use px wherever dp [...] is stated.")
• Microsoft’s Windows Phone UI Design and Interaction Guide (PDF) suggests a touch target size of 34px with a minimum touch target size of 26px
• Human Fingertips to Investigate the Mechanics of Tactile Sense (PDF) - found that the average width of the index finger is 1.6 to 2 cm (16 – 20 mm) for most adults. This converts to 45 – 57 pixels, which is wider than what most mobile guidelines suggest. A touch target that’s 45 – 57 pixels wide allows the user’s finger to fit snugly inside the target. The edges of the target are visible when the user taps it. This provides them with clear visual feedback that they’re hitting the target accurately. They’re also able to hit and move to their targets faster due to its larger size. This is consistent with Fitt’s Law, which says that the time to reach a target is longer if the target is smaller.
• One-Handed Thumb Use on Small Touchscreen Devices - target sizes should be at least 9.2 mm for single-target tasks and 9.6 mm for multi-target tasks in order to keep the dimensions of the targets as small as possible without decreasing performance and preference
• Microsoft Guidelines for Building Touch Friendly Sites - a target is at least 11mm (about 40px) square with at least 2mm (about 10px) of padding around (note that if 11mm is roughly equivalent to 40px, then 2mm should actually be roughly equivalent to 7.5px, but rounding up to 10px seems appropriate for simplicity's sake)
• Microsoft Design Language (PDF) - minimum touch target size of 44 EP × 44 EP ("effective pixels", Microsoft's own density-independent unit of measure - roughly equivalent to 1 CSS px when using ideal viewport)

Boneyard: Summary of Research on Touch Target Size

Testability

1. Locate all touch targets/actionable items and identify if the inputs are defined for course or fine pointing accuracy
2. Review the page is set to the device ideal viewport (e.g. the viewport is set to device-width)
3. Identify what size in pixels the touch target is set to in the CSS
4. Verify the visible target size is at least 44px by 44px for pointer inputs

Techniques

M030 Multiple Elements: When multiple elements perform the same action or go to the same destination (e.g. link icon with link text), these should be contained within the same actionable element. This increases the touch target size for all users and benefits people with dexterity impairments. It also reduces the number of redundant focus targets, which benefits people using screen readers and keyboard/switch control.

M002 Touch Target: Ensuring that touch targets are at least 44px by 44px.

FM005 Failure: touch target is less than 44px x 44px at the default viewport size

Potential technique to ensure inline links provide sufficiently large activation target - https://codepen.io/patrickhlauke/pen/aBNREe (this will still prove problematic for paragraphs with high link density, which - depending on viewport size etc - can result in link activation targets overlapping; authors will need further techniques - some of which may be editorial - to ensure this does not happen)