Target Size

[kwahlbin]

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 https://github.com/w3c/csswg-drafts/issues/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 http://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 - http://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)

[jnurthen]

Needs exclusions when there are multiple ways to do something. For example the letters A-Z at the side of the contacts app on iOS has a very small touch target - but is not the only way of operating the application. It would be impossible to make each of the letters A-Z fit on the screen with a 48x48px touch target but this is an inherently useful UI. It needs to be allowed.

[DavidMacDonald]

Could address James comment by creating exception.

• except where another means of performing the function meets the minimums.

[awkawk]

@jnurthen - the touch target for the A-Z seems to be 40px wide and hundreds of px tall. That control is essentially a slider.

Are there other examples of well-known, small UI that we should be thinking about?

[goetsu]

dots navigation for carousel

[goetsu]

regarding the issue mentionned by @kwahlbin for paragraph with high density links we maybe can exclude those kind of links (links within text) form this requirements

[mbgower]

I may be missing something here, but would not any short link like this #60 fail this criteria? If I open this page up on mobile device and the entire page is displayed, this link would be a wee speck on the screen.

[mbgower]

Screen shot from iphone 6s showing the current page Even though this page is being handled dynamically by the Safari browser to size to viewport, the three character target "#60" in this image barely appear to meet this requirements. Any kind of 2-character footnote link would fail, I think. And of course viewing a whole page in the browser would make the link microscopic.

[kwahlbin]

Patrick mocked up an example where you can have a larger touch area for short links: http://codepen.io/patrickhlauke/pen/aBNREe

[mbgower]

How about some language that restricts this to user controls other than text links, except where those links are functioning in another role (i.e., as a substitution for a button or menu item).

[awkawk]

It seems like the issues we have outstanding right now are:

• Controls which don't meet the width or height (e.g. a-z tall vertical control in iOS contacts).
• Text links that are short in character length and may not meet the requirement
• Text links that are smaller in height than the requirement
• Need to account for non-conforming controls that are not the only way to accomplish a task
• I wonder whether a target that is short in one dimension but large in the other might be ok.

An update to address the exception James talked about: All functionality of the content is operable through targets which are sufficiently large. The size of the target in relation to the visible display at the default viewport size is at least:

• 48px by 48px for pointer inputs with coarse pointing accuracy (such as a touchscreen)
• 24px by 24px for pointer inputs with fine pointing accuracy (such as a mouse, trackpad or stylus) where px is a CSS pixel when the page is using the device ideal viewport.

[patrickhlauke]

Coming in late on this...

@DavidMacDonald

Could address James comment by creating exception.

• except where another means of performing the function meets the minimums.

Agree. Perhaps adding this after the "... device's ideal viewport" (note the missing "'s" in the current SC) sentence. Wonder if it should be reworded to just "except where another conforming means of perfroming the function is available", removing the "minimums", which would open up the possibility that the alternative means is not a link/button, but some other conforming mechanism/way of doing things.

@mbgower

I may be missing something here, but would not any short link like this #60 fail this criteria?

Yes, these would be examples of failure. They do prove to be problematic for users. Some user agents may provide UI enhancements (particularly on mobile) that help to minimise this. a UA may for instance artificially extend the "tappable" area of small controls - if a user taps somewhere that is not an actual target, a UA may check what the nearest target to that point is and, if it's within a certain threshold, pretend that the tap happened on the target. however, this is dependent on the UA, and cannot be relied upon.

And of course viewing a whole page in the browser would make the link microscopic.

If the page does not adapt correctly to small screen devices (i.e. does not set a mobile-friendly viewport, and is therefore shown in a scaled down desktop view), it will likely fail from the get-go. One of the sufficient techniques then for this would be to, at the very least, set a mobile-friendly viewport (ideally the "ideal viewport", i.e. width=device-width).

How about some language that restricts this to user controls other than text links, except where those links are functioning in another role (i.e., as a substitution for a button or menu item).

I would be not be too thrilled if we started to exclude things that are, in fact, actual problems for users. Techniques to avoid the problem do exist, and can be implemented in most cases with no adverse effect on visual layout

@awkawk (slightly reordering/regrouping your bullet list)

It seems like the issues we have outstanding right now are:

• Controls which don't meet the width or height (e.g. a-z tall vertical control in iOS contacts).
• Need to account for non-conforming controls that are not the only way to accomplish a task

Should be taken care of if we add the exemption for alternative mechanisms.

• Text links that are short in character length and may not meet the requirement
• Text links that are smaller in height than the requirement
• I wonder whether a target that is short in one dimension but large in the other might be ok.

These are actual problems for users (regardless of how common they may be, and regardless of what heuristics UAs may include to minimise their problem), so I'd say they should fail the SC.

[patrickhlauke]

Having said all the above, one potential fallback position I could just about live with would be to specify that, for coarse inputs, at least one of the dimensions (width or height) satisfies the minimum of 48px, and that none of the dimensions fall below 24px, if the control/link is not (and this is where my wording capabilities fail me) "critical"/"primary"/"essential" ? It will still be problematic for certain users to accurately hit those targets (without doing other things such as zooming in, or relying on potential UA accommodation), but it will be an inconvenience rather than something that stops them from performing the primary function/task. The difficulty here would be to define this in such a way as not to provide too many loopholes that lets authors claim they don't need to bother...

[awkawk]

I'm worried about the inline links. There are valid use-cases for short links (foot/end notes comes to mind first) and even very short and clear links (e.g. "Help") may run afoul of the horizontal size requirement (and almost certainly will have a problem with the vertical size requirement). Are there other common use cases for short links?

If we are requiring the ability to resize text with reflow (yes, I know that this is a problem for mobile browsers today) would this have any impact on our thinking for text links? Is the supported population of users the same for both the text resizing and the target size SC? I can imagine that a user with hand tremors would benefit from larger targets even if they are comfortable reading small text, but I also know that if we are saying that links need to be 48x48 (or 48x24) that we are saying in most cases that the default text size needs to be larger than people use now, which makes this SC blur into the other.

[awkawk]

For reference, on my iOS phone (6s) the dialog that comes up often has buttons that are 51pxx44px, which meets apple's standard for the height and exceeds it for the width.

I think that given that Apple and Microsoft have 44 as the basis for their guidance and Android uses 48 we should be going with 44 as the implemented reality for WCAG 2.1.

[patrickhlauke]

I can imagine that a user with hand tremors would benefit from larger targets even if they are comfortable reading small text, but I also know that if we are saying that links need to be 48x48 (or 48x24) that we are saying in most cases that the default text size needs to be larger than people use now, which makes this SC blur into the other

no. this is not about the text size, but about the area that responds to a click/tap. this area may be transparent/invisible, and indeed if you look at the guidance documents from Apple/Google/Microsoft, this is clarified. see also my very rough example here http://codepen.io/patrickhlauke/pen/aBNREe (where, for illustrative purposes, i've made the actionable area green...but in real deployment it would be see-through)

in short no, i think the users affected by this are distinct from users that would require larger text/reflow. and if we accepted that zoom/reflow is an acceptable way to satisfy this, then authors would have an immediate get-out-of-jail card here to do nothing, simply relying on the fact that "if the control's too small, just zoom in..."

[patrickhlauke]

I think that given that Apple and Microsoft have 44 as the basis for their guidance and Android uses 48 we should be going with 44 as the implemented reality for WCAG 2.1.

personally, i'd be happy to drop the requirement to 44 x 44 (for coarse) / 22 x 22 (for fine).

[patrickhlauke]

I'm worried about the inline links. There are valid use-cases for short links (foot/end notes comes to mind first) and even very short and clear links (e.g. "Help") may run afoul of the horizontal size requirement (and almost certainly will have a problem with the vertical size requirement). Are there other common use cases for short links?

also, this SC wouldn't forbid short links. it would simply require that if short links are used, their actual tappable/clickable area is extended to make them more easily actionable (again, see my example above for a rough idea). the only problem with that as a proposed technique comes when there's a high density of links (lots of links close together), where extending the tappable/clickable area would result in overlaps. but again, this would be an actual problem for users, so i don't think it warrants an exemption. it may be more technically challenging to implement - and go more towards "softer" advice of, basically, not sprinkling lots of inline links close together.

[patrickhlauke]

i'd also note that it's not straightforward to write some form of exception for "links", unless we want to be way more specific. what about a 5px x 5px image wrapped in a link...would that then count as a "link" that can be exempted? what if that "link" is in fact a crucial trigger for some functionality? etc

[awkawk]

no. this is not about the text size, but about the area that responds to a click/tap. this area may be transparent/invisible, and indeed if you look at the guidance documents from Apple/Google/Microsoft, this is clarified. see also my very rough example here http://codepen.io/patrickhlauke/pen/aBNREe (where, for illustrative purposes, i've made the actionable area green...but in real deployment it would be see-through)

Sure, and that could be a user agent or assistive technology setting also (and if it was then authors would need to do less). But what happens when the links are close together? In your example I can adjust my window and make the green areas overlap, and that might trigger a failure since only one of the links has the large target area then.

[patrickhlauke]

But what happens when the links are close together?

then the content fails this SC. don't think we can rely on user agents having built-in functionality to disambiguate taps. And even if mobile user agents sometimes provide this, there isn't an equivalent that i'm aware of for mouse users (who are also covered by this, since they may have the same difficulty in precisely targetting controls/links)

[patrickhlauke]

Thinking here about techniques that can be suggested: if we provide an exemption for controls/links that are too small, provided that alternative methods of achieving the same thing are available, one way around the "small inline links densely packed" problem would be to offer an alternative listing of those links, more widely spaced (like a generously-enough vertically spaced bullet list) after the main content?

[goetsu]

regarding inline links and short text in button or link I keep thinking it must be removed from the scope of this SC, there is no discrimination in case of inline link/button with short text because they are short by nature and not by intent of the author We have same exception for links that are not clear enough for anyone, wcag doesn't require to make them clear @patrickhlauke the issue with your demo is if you have a fix layout you can end up with two links in different lines with extra spacing from one hover the other cf capture

[awkawk]

then the content fails this SC.

I think that will be a problem as it would cause problems for content management systems where all content is written separately from the WYSIWYG view. I don't think that people would find it reasonable that links can never be on adjacent lines.

[patrickhlauke]

@goetsu @awk i'm struggling to see how we can open the door to allow these sorts of things to be exempt, without accidentally making the whole point of the SC moot. because essentially there's a danger of saying "make sure your links and controls are at least X size, otherwise users can't confidently interact with them...oh, unless you have lots of those links/controls next to each other, in which case it's fine..."

note that there are other related things that can be done...increasing line-height will help, and potential alternatives that list links, as mentioned before.

[patrickhlauke]

unless, for single A at least, we try to focus the applicability of this to just (to pick from the current proposed description):

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

but those would need some further clarifications/definitions so as not to allow too many loopholes

[patrickhlauke]

@goetsu

@patrickhlauke the issue with your demo is if you have a fix layout you can end up with two link in different line with extra spacing on hover the other cf capture

to clarify, yes my example would fail this SC for that as well. as an author, i'd have to look for further alternatives to satisfy these situations. it was only a proof of concept for the idea of extending tappable/clickable area without impacting design, not a technique to illustrate a definitive pass specifically.

[goetsu]

simply exclude " links within a paragraph or other block of text" as it's done on https://www.w3.org/TR/WCAG-TECHS/F73.html for example

[patrickhlauke]

simply exclude " links within a paragraph or other block of text"

and what if it's not a link, but a <button>? or a graphical link of a tiny icon?

and fundamentally, those links within a paragraph do constitute a problem. exempting them does not remove the actual problem to the user which the SC is trying to address?

[goetsu]

and what if it's not a link, but a ?

textual links or buttons within a paragraph or other block of text

or a graphical link of a tiny icon?

as I already say if textual links or buttons within a paragraph or other block of text is by nature tiny there is no discrimination. It's an usability for everyone and we must use exception as in 2.4.4 (ambiguous for every user exception)

[patrickhlauke]

i think i'd be far more inclined to limit the applicability of the SC based on a link/control's purpose and importance, rather than based on whether or not they're part of a block of text or similar - i.e. something along the lines of what i proposed above https://github.com/w3c/wcag21/issues/60#issuecomment-277295964 (but perhaps with some tweaks)

and to clarify: in that case, if you're using inline links in a paragraph as the only means to trigger essential functionality in your page, then yes you as an author are doing it wrong and your page fails...no "but it's part of a block of text" to save you there

[patrickhlauke]

as I already say if textual links or buttons within a paragraph or other block of text is by nature tiny there is no discrimination.

not if they're small but still operable for somebody without tremors, using a head-wand to activate a touchscreen, or similar.

[goetsu]

not if they're small but still operable for somebody without tremors, using a head-wand to activate a touchscreen, or similar.

that's why anyway you have to test with real users to conform to WCAG

[patrickhlauke]

that's why anyway you have to test with real users to conform to WCAG

that's orthogonal to the discussion here. doing a WCAG audit does not require me as an auditor to run real user testing, no?

[goetsu]

it depend you at least have to check support in AT "The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,"

and AT def include : "alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations."

So back to this SC if user of a "classic" mouse with tremor can't click the link it's (sadly in my opinion but that's another question) no in the scope of WCAG conformance but if this user use a switch access for example it's in the scope and you must check that it work (with real user or by yourself as you want)

[jnurthen]

I want to give a real-world example to frame this discussion.

Here is a Football (Soccer) league table from the BBC's web site. Currently each team name in the table is a link of 16px with 8px padding above and below. This could result in a height of 32px for a touch target. In this scenario I can see 19 of the 20 teams fully - and if I were to scroll so the header of the table were not visible I could see all 20 teams.

In this next screen I increased the padding to 14px on each side, which results in a height of 44px. Here I can see 14 of the 20 teams

The last one has 16px padding, resulting in a 48px height. Now I can see 13 of the 20 teams.

Now - if a minimum touch size was introduced for this content, and I wanted to comply with it my solution would be to remove the links to the teams rather than increasing the size - as there are many other ways to get to the same content which can be found when clicking on the link - but I argue that this would decrease the usability of the site. If we do require 44 or 48 px touch target sizes we need to find a way to allow content such as this.

[awkawk]

It all comes down to James's football leagues! :)

One thought that might be too specific to this example is that if the entire row was the link and we allowed for 44x22 (or 48x24) then the first one would work.

It wold be good to hear from users about this type of situation. Similarly, I wonder if apple has received complaints about the a-z vertical slider?

[awkawk]

By the way, the way I was proposing to handle the exceptions where a task could be accomplished in another way was with this line:

"All functionality of the content is operable through targets which are sufficiently large."

In essence, all functionality needs to be operable through large-enough targets, but not ONLY through large-enough targets.

[patrickhlauke]

The last one has 16px padding, resulting in a 48px height. Now I can see 13 of the 20 teams.

and to me, that example would be the most small-screen / coarse pointer input friendly one of the bunch, yes. (and incidentally, it looks very similar to scrolling listviews in native iOS apps, if you make the whole row clickable/tappable as @awkawk mentions).

if your argument is that making sure users can confidently tap/activate a control with these minimum sizes reduces the number of possible items on the screen, then of course, yes. density/number of actionable targets on screen is of course inversely proportional to the minimum target size. if authors do want high information density, then that's fine...but high density of small, actionable targets will cause problems that we're trying to avoid with this SC?

taking your first example, I would have some difficulty in unambiguously tapping only the link i wanted (e.g. when trying to use the phone with only one hand). a user with mobility impairment / tremors / etc would likely find it very difficult without zooming into the page. (and if the additional point here is "if we do this, even the BBC would have to modify their layout", then i'd say yes, they're arguably breaking their own advice here)

[patrickhlauke]

By the way, the way I was proposing to handle the exceptions where a task could be accomplished in another way was with this line:

"All functionality of the content is operable through targets which are sufficiently large."

In essence, all functionality needs to be operable through large-enough targets, but not ONLY through large-enough targets.

If the last part can be added/expanded upon in the understanding section, I'd be all for that addition

[patrickhlauke]

In this scenario I can see 19 of the 20 teams fully - and if I were to scroll so the header of the table were not visible I could see all 20 teams.

worth noting as well that while this is true on what i'm assuming to be an iPhone 5 or 6 (?), it depends on the aspect ratio of the device's screen. so it's not a case that we'd be asking authors to break this delicately constructed layout whose purpose was explicitly to show the whole table in the viewport, as that is even today not true for all mobile devices.

[mbgower]

i think the users affected by this are distinct from users that would require larger text/reflow. and if we accepted that zoom/reflow is an acceptable way to satisfy this, then authors would have an immediate get-out-of-jail card here to do nothing, simply relying on the fact that "if the control's too small, just zoom in..."

This statement, and this SC overall, has been nagging at me. Having given it a lot of thought, I’ve reached some issues that I would like to get addressed/discussed.

1. Specifying minimum target size may not be necessary, and contradicts precedent in other areas, namely text size.
2. The SC is biased to mobile, and can result in issues when implementing on desktop.
3. We have other proposed SCs which can allow a user to modify target size to their needs. In what way are they insufficient, and to what degree is that an author responsibility?
4. We still need clarity on when an author needs to provide a mechanism, and when it is sufficient to properly author content and allow the user agent or AT to provide the mechanism.

Each of these statements is a big topic, so I'm going to split the argument down into 4 separate comments. If this is just too much for the thread, and you want me to take them offline, just let me know and I'll remove them.

[mbgower]

1: Is specifying Target Size necessary?

I’d like to look at the parallel consideration for text size. WCAG 2.0 does not prescribe a minimum size for text. Instead, WCAG focuses on allowing a user to adjust the text size to improve the accessibility, regardless of its starting size. In what way is target size different? There’s plenty of design material on what should constitute the minimum text size for a website. Such usability practices provide a rough baseline for text size; but there may be reasons an author opted for a larger or smaller text size. So in addition to several technical reasons which make it tough to be prescriptive, I think it was a good move to not impose a minimum text size on all web sites. Similarly, we see there are usability recommendations from Apple, Google and Microsoft for target size in native applications, which are pretty close to what are being proposed for minimum target size for accessibility. So what is gained in making those usability recommendations prescriptive?

[mbgower]

Issue 2: Mobile

I mentioned vendor guidelines for target size. An important point is that these seem to be about native application design, not the display of web content on a mobile device. When we apply software authoring guidelines to the more malleable web environment, we run into issues. Yes, authors may design controls for a site, but the content that resides in the main region may include links whose position and size authors cannot control/anticipate, given the malleable presentation of web content, especially on the desktop. And what about resolution on different devices? I have a 23-inch touch monitor at home. At the default resolution on this monitor which my kids use, pretty much any web page I open fully expanded is going to be tough to select with my finger, whether or not it fails the proposed minimum target size for text links on the screen.

[mbgower]

Issue 3: why can’t requirements from other candidate SCs be used to improve the target size?

78 Ability to Override (text styling) provides a requirement that authoring not prevent the user from increasing the line height, letter spacing or word spacing, all of which would allow a user to increase the target size of links. This solution seems very similar to the alterations suggested for the football scores in order to achieve a larger target size.

With #77 Resize Content, we have a draft requirement that authoring practices support the ability for a user agent to zoom to 400% without horizontal scrolling. I agree not all users would see that as optimal, but it certainly provides a means to increase the target size for all controls. Note that pinch to zoom does not meet Resize Content without horizontal "scrolling." (Even if the little grey scroll regions don't necessarily appear, pinch to zoom is still just magnifying, not reflowing content to viewport.)

Neither of these SCs suggest an author does nothing ('get out of jail free'). Content creators need to properly author to ensure the user agent or another mechanism can provide the resize content or restyle text without failing specific criteria.

[mbgower]

Issue 4: Clarity on author mechanisms

Why are we suggesting author-supplied mechanisms are required here (such as Patrick’s CSS demo) when with Resize Content we seem amenable to giving a pass on the requirement when the user agent doesn’t supply the mechanism, as on a mobile browser? I’m not arguing either way here, but suggesting that we should be consistent: either it’s fine that the author just authors properly and lets the user agent be the mechanism where it is available, or else the author has a responsibility to offer content resize and target size minimum regardless of the mechanisms available from the user agent. I’m aware I’m making this a binary argument and some middle ground is achievable; I’m just trying to get clarity.

[patrickhlauke]

Picking up on some of the bits here:

Specifying minimum target size may not be necessary, and contradicts precedent in other areas, namely text size.

However, a similar precedent I'd say are 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced). Why does WCAG 2.0 prescribe color contrasts, when users agents allow users to remap colors/define their own custom stylesheets?

I mentioned vendor guidelines for target size. An important point is that these seem to be about native application design, not the display of web content on a mobile device.

Even for native, platforms do provide built-in zoom functionality (to blow up the whole screen and pan around the viewport). So in a way, even native apps wouldn't really need any specified minimum target sizes...

Is defining minimum activation target size skirting the line between usability and accessibility? Perhaps. I'd still argue that users with mobility impairments or tremors are disproportionately more disadvantaged than users without those issues. But sure, if they zoomed into the content/screen/viewport/page sufficiently, they could overcome those issues.

And what about resolution on different devices? I have a 23-inch touch monitor at home. At the default resolution on this monitor which my kids use, pretty much any web page I open fully expanded is going to be tough to select with my finger, whether or not it fails the proposed minimum target size for text links on the screen.

I have a 23 inch monitor (not touch, sadly, but I do have smaller-sized touch-enabled laptops) running at 1920x1080. A 44px x 44px (and even a 44px x 22px) region is just about a comfortable size for me to activate with a finger unambiguously. Of course, since authors are not directly in control of the actual physical size their CSS is rendered at (and no way to query the actual physical size of the display), any measurement given will rely on devices having a "sane" default and for the user to have set their resolution (if under their control) to a comfortable setting (i.e. not running a 23" monitor at full 4k or similar). For mobile/tablet devices, the "ideal viewport" part of this SC takes care of this (provided mobile device/OS manufacturers use a "sane" ideal viewport, e.g. in most cases 320 CSS px width in portrait on a mobile, regardless of actual physical size of the screen / hardware pixel density).

Also worth reiterating that this is not purely about touch, but covers mouse as well.

Having said all that, if we truly don't think it's a problem because users that find controls too small should be able to zoom, then I guess yes, this SC would be unnecessary (but then I'd query why 1.4.3 and 1.4.6 in current WCAG 2.0 are there...)

[mbgower]

if we truly don't think it's a problem because users that find controls too small should be able to zoom

I think resizing content is one possible method to increase target size; however, as mentioned, i don't think pinch to zoom meets the Resize Content criteria as proposed -- having to pan the viewport is a form of 2-dimensional scrolling. My other concern about pinch to zoom it that it relies on a fine motor control affordance (pinch) to overcome another fine motor control challenge (target size). That seems problematic.

Let me be clear that I think it is beneficial to allow users to increase target size of any controls. I just see issues arising from how we're trying to bring that about. Would things become clearer if we tried to distinguish between text-only links and from other forms of controls?

I'd query why 1.4.3 and 1.4.6 in current WCAG 2.0 are there...

I can think of a few reasons 1.4.3 is different:

• contrast minimum is not well established as a usability criterion, so is filling a gap
• prescribed contrast ratios are applicable across a wide variety of devices and modalities (barring some quirks of white colour balance)
• the requirement addresses contrast issues with images of text, which users cannot easily overcome

[patrickhlauke]

Almost feels like (based on recent discussions) that 1.4.3 / 1.4.6's language should, instead of mandating a particular ratio, have something along the lines of "authors should not PREVENT users from having text at a certain contrast ratio", and specifically call out the fact that images of text can't be easily modified by a user (using high contrast mode, user styles, or similar)...

In any case, if it's felt that this particular SC here is more of a usability, rather than an accessibility, concern (provided pages don't attempt to block users from resizing/zooming), then I'd say defer to Silver for potential inclusion as a best practice/usability technique, rather than a hard pass/fail for accessibility in WCAG 2.1. (/cc @kwahlbin suggest MATF discussion on this)

[kwahlbin]

The MATF is fine with having 44 x 44px requirement with exception for inline link, button or control. If inline link, button or control performs essential functionality or is the only way to perform an action then one dimension is 44px and the other is at least 22px.
Note: the 48x48px came from the research quoted in the Evidence section.

[DavidMacDonald]

Suggested rewording given MATF consensus above:

Except for inline interactive elements in blocks of text, the size of each target in relation to the visible display at the default viewport size is at least:

• 44px by 44px for pointer inputs with coarse pointing accuracy (such as a touchscreen)
• 24px by 24px for pointer inputs with fine pointing accuracy (such as a mouse, trackpad or stylus)

Inline interactive controls in blocks of text have no size requirements unless they perform essential functionality, or are the only way to perform an action. Then one dimension is at least 44px and the other is at least 22px.

Essential: defined in WCAG 2