This repository has been archived by the owner. It is now read-only.

Target Size #60

Closed
kwahlbin opened this Issue Nov 29, 2016 · 372 comments

Comments

@kwahlbin
Contributor

kwahlbin commented Nov 29, 2016

Current versions of SC and Definitions

Open issues and Surveys

Open issues: SC Status page

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 w3c/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

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

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Dec 2, 2016

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.

jnurthen commented Dec 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 4, 2016

Contributor

Could address James comment by creating exception.

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

DavidMacDonald commented Dec 4, 2016

Could address James comment by creating exception.

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

@awkawk awkawk self-assigned this Dec 15, 2016

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Dec 19, 2016

Member

@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?

Member

awkawk commented Dec 19, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Dec 26, 2016

dots navigation for carousel

goetsu commented Dec 26, 2016

dots navigation for carousel

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Jan 3, 2017

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

goetsu commented Jan 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

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.

Contributor

mbgower commented Jan 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

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.

Contributor

mbgower commented Jan 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Jan 18, 2017

Contributor

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

Contributor

kwahlbin commented Jan 18, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

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

Contributor

mbgower commented Jan 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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

awkawk commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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.

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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.

Member

awkawk commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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

Member

awkawk commented Feb 3, 2017

sendbutton
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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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.

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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.

Member

awkawk commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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)

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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?

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Feb 3, 2017

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
capture d ecran 2017-02-03 a 17 24 20

goetsu commented Feb 3, 2017

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
capture d ecran 2017-02-03 a 17 24 20

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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.

Member

awkawk commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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

Member

patrickhlauke commented Feb 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Feb 3, 2017

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

goetsu commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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?

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Feb 3, 2017

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)

goetsu commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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 #60 (comment) (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

Member

patrickhlauke commented Feb 3, 2017

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 #60 (comment) (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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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.

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Feb 3, 2017

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

goetsu commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 3, 2017

Member

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?

Member

patrickhlauke commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Feb 3, 2017

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)

goetsu commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Feb 3, 2017

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.

screenshot of league table on an iphone 6 display, showing 19 of the 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

screenshot of league table on an iphone6 display, showing 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.

screenshot of league table on an iphone6 display, showing 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.

jnurthen commented Feb 3, 2017

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.

screenshot of league table on an iphone 6 display, showing 19 of the 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

screenshot of league table on an iphone6 display, showing 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.

screenshot of league table on an iphone6 display, showing 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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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?

Member

awkawk commented Feb 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 3, 2017

Member

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.

Member

awkawk commented Feb 3, 2017

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.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot May 10, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower May 10, 2017

Contributor

I will once again put into question why people here seem so obsessed with talking about "text link" rather than being more holistic about ANY kind of actionable inline control (like an image link, or a , or whatever). It makes no difference (as it still applies to text links) but doesn't somehow magically make an exception for text links versus other types of actionable controls

@patrickhlauke , and I will once again list a few reasons:

Importance

At one point, I'm pretty sure this SC addressed the notion of 'important controls'

  • a text link does not necessarily need to be an 'important' control on the page. Lots of times folks link off to aside topics, etc. If a link is important (which often means it is aping another control type) it is normally isolated from body text
  • on the other hand, I cannot picture many real-life scenarios where a button is not an important control. So if someone make a tiny button, it has a much higher likelihood of impeding important user actions. So why give a pass for such a thing?

Design Intent

  • the act of making text into a link is a moment's effort. Until this SC came along, a consideration for target size of a text link in a paragraph didn't exist. And depending on the authoring tool, authors have not typically had control for the link size.
  • on the other hand, when someone goes to the trouble of creating an image small enough to fail this SC, and also makes that image actionable, I don't see why we'd be wanting to give an exception in the name of a more holistic approach

Frequency

Yes, I know. 'Just because something happens a lot doesn't make it any more right.' But if we're looking for power in the exception, let's focus on the billions of existing inline links that could potentially fail target size, rather than the paltry number of image links that could.

If you want to expand the exception to make it more uniform, not only am I not obsessed about it, but I'm not going to lose any sleep. But not including an exception that encompasses inline links puts the SC at risk.

Contributor

mbgower commented May 10, 2017

I will once again put into question why people here seem so obsessed with talking about "text link" rather than being more holistic about ANY kind of actionable inline control (like an image link, or a , or whatever). It makes no difference (as it still applies to text links) but doesn't somehow magically make an exception for text links versus other types of actionable controls

@patrickhlauke , and I will once again list a few reasons:

Importance

At one point, I'm pretty sure this SC addressed the notion of 'important controls'

  • a text link does not necessarily need to be an 'important' control on the page. Lots of times folks link off to aside topics, etc. If a link is important (which often means it is aping another control type) it is normally isolated from body text
  • on the other hand, I cannot picture many real-life scenarios where a button is not an important control. So if someone make a tiny button, it has a much higher likelihood of impeding important user actions. So why give a pass for such a thing?

Design Intent

  • the act of making text into a link is a moment's effort. Until this SC came along, a consideration for target size of a text link in a paragraph didn't exist. And depending on the authoring tool, authors have not typically had control for the link size.
  • on the other hand, when someone goes to the trouble of creating an image small enough to fail this SC, and also makes that image actionable, I don't see why we'd be wanting to give an exception in the name of a more holistic approach

Frequency

Yes, I know. 'Just because something happens a lot doesn't make it any more right.' But if we're looking for power in the exception, let's focus on the billions of existing inline links that could potentially fail target size, rather than the paltry number of image links that could.

If you want to expand the exception to make it more uniform, not only am I not obsessed about it, but I'm not going to lose any sleep. But not including an exception that encompasses inline links puts the SC at risk.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma May 10, 2017

Contributor

John,

As I understood from research on user needs, user possibilities with restrictions to go horizontal / vertical it was not an option to do a bit less height and add it to the with or vice versa.

Also for setting minimums of either height or width when having more links next to each other on one line (maybe consistent of 2 of 3 characters) and the possibilities to reflow will still end up in issues for overlap or lack of enough total surface area.

Contributor

jake-abma commented May 10, 2017

John,

As I understood from research on user needs, user possibilities with restrictions to go horizontal / vertical it was not an option to do a bit less height and add it to the with or vice versa.

Also for setting minimums of either height or width when having more links next to each other on one line (maybe consistent of 2 of 3 characters) and the possibilities to reflow will still end up in issues for overlap or lack of enough total surface area.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc May 10, 2017

Contributor

Patrick wrote:

I'm in favor of abandoning this SC / deferring this to a less stringent "usability best practices" type suggestion...

Given that this has the most comments on github, and we are circling the same options, I suggest putting in the no-exceptions version at AAA and saying in the "release notes" that we intend to tackle this again next time.

Contributor

alastc commented May 10, 2017

Patrick wrote:

I'm in favor of abandoning this SC / deferring this to a less stringent "usability best practices" type suggestion...

Given that this has the most comments on github, and we are circling the same options, I suggest putting in the no-exceptions version at AAA and saying in the "release notes" that we intend to tackle this again next time.

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer May 10, 2017

Contributor
Contributor

detlevhfischer commented May 10, 2017

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma May 10, 2017

Contributor

+1 to WCAG 2.1 AA and inline links exempted

Contributor

jake-abma commented May 10, 2017

+1 to WCAG 2.1 AA and inline links exempted

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 11, 2017

Contributor

So what I am hearing is that the solution to inline text links is to exclude it from the requirements.

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 a text link in a block of text.
  • Cannot be Modified: the target is controlled by the user agent and cannot be modified.

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

Contributor

kwahlbin commented May 11, 2017

So what I am hearing is that the solution to inline text links is to exclude it from the requirements.

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 a text link in a block of text.
  • Cannot be Modified: the target is controlled by the user agent and cannot be modified.

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

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer May 11, 2017

Contributor
Contributor

detlevhfischer commented May 11, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke May 11, 2017

Member

@mbgower

on "importance", we established that "important controls" was a really fluffy, not-reliably definable/testable concept. it seems that instead you're now inferring importance through what you believe are characteristics of what is and isn't usually an important control (that text links by their ususal use are not important, and that authors would not be likely to put important other types of links/controls inside blocks of content).

on "design intent", you're inferring author intent based on how easy/hard a text link is to make compared to other types of links/controls. inferring that authors who just made a small word inside a text block a link can't be blamed for not realising that it will likely end up having a small actionable/clickable target area, whereas if they created an image they're likely doing it on purpose. no word on <button>s or other controls (like an inline checkbox or similar).

so in both cases, there's a lot of inferring author intent / nature of a control based on..."authors wouldn't do this"/"if they did that, they problably meant it".

on "frequency", you argue we should focus on the most common examples of failures to exempt. by expanding the wording from just "text links" to "actionable controls" (which would include links), we'd still be covering those just fine.

If you want to expand the exception to make it more uniform, not only am I not obsessed about it, but I'm not going to lose any sleep.

That's what I've been saying. If we make an exception, don't special-case "text links" over other types of inline actionable controls unless you have more rationale than inferred intent.

But not including an exception that encompasses inline links puts the SC at risk.

Never said the exception should be dropped. the proposed "actionable controls" includes the concept of "text links".

Member

patrickhlauke commented May 11, 2017

@mbgower

on "importance", we established that "important controls" was a really fluffy, not-reliably definable/testable concept. it seems that instead you're now inferring importance through what you believe are characteristics of what is and isn't usually an important control (that text links by their ususal use are not important, and that authors would not be likely to put important other types of links/controls inside blocks of content).

on "design intent", you're inferring author intent based on how easy/hard a text link is to make compared to other types of links/controls. inferring that authors who just made a small word inside a text block a link can't be blamed for not realising that it will likely end up having a small actionable/clickable target area, whereas if they created an image they're likely doing it on purpose. no word on <button>s or other controls (like an inline checkbox or similar).

so in both cases, there's a lot of inferring author intent / nature of a control based on..."authors wouldn't do this"/"if they did that, they problably meant it".

on "frequency", you argue we should focus on the most common examples of failures to exempt. by expanding the wording from just "text links" to "actionable controls" (which would include links), we'd still be covering those just fine.

If you want to expand the exception to make it more uniform, not only am I not obsessed about it, but I'm not going to lose any sleep.

That's what I've been saying. If we make an exception, don't special-case "text links" over other types of inline actionable controls unless you have more rationale than inferred intent.

But not including an exception that encompasses inline links puts the SC at risk.

Never said the exception should be dropped. the proposed "actionable controls" includes the concept of "text links".

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer May 11, 2017

Contributor
Contributor

detlevhfischer commented May 11, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc May 11, 2017

Contributor

Shouldn't it just re-play what the start of the SC uses?

Inline: The target is in a block of text.

Contributor

alastc commented May 11, 2017

Shouldn't it just re-play what the start of the SC uses?

Inline: The target is in a block of text.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke May 11, 2017

Member

@alastc that sounds good to me... (assuming we have a solid definition what is a "block of text", or is it clear enough? i.e. a single short-ish line of text can become a "block" of 2 or more lines depending on viewport width)

Member

patrickhlauke commented May 11, 2017

@alastc that sounds good to me... (assuming we have a solid definition what is a "block of text", or is it clear enough? i.e. a single short-ish line of text can become a "block" of 2 or more lines depending on viewport width)

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 May 12, 2017

Contributor

@johnfoliot wrote/quoted " "You may be surprised to learn that current touchscreens sense only the
geometric center of a user’s contact patch, or its *centroid, *rather than
its entire area, as shown in Figure 2. So touchscreens can’t communicate
the size of a user’s contact patch to a mobile phone—.. Because a device uses only the centroid to determine what a user is tapping, the extent of the contact patch doesn’t matter

Yes, the mobile task force is aware of this - nothing in this SC indicates otherwise.

@johnfoliot wrote "I will argue that this addresses the point I tried to raise on today's
call, that asking for a 44 px square touch target is problematic from
multiple perspectives, one being that "touch targets" are not universally
square (or rectangular) per the touch screen - yes, the target will
remain/"outline"

I don't see this as being problematic. We could say that the control has a radius from the center of 44 CSS pixels which would allow for round targets -- but I don't think that adds a lot and makes it more difficult to test. The touch centroid is a single point and thus as long as the single point falls in the target area the control will recognize that touch.

@johnfoliot ""Even with iOS clearly in second place behind Android, the Apple standard
size for touch targets sticks with us, but 44 pixels is not a physical
size. And with several device operating systems on the market—and Apple
converting pixels to a device-independent measurement they call a point—we
cannot even translate 44 pixels, or points, to a single actual size."
(source:"

This is precisely why we indicate these as CSS pixels with the default viewport set. There is no way for the author to know what devices people are using so we are not able to put a physical size in. Since CSS pixels are generally consistent with the default viewport width is set it is the solution to this challenge.

@johnfoliot While I won't dismiss or denigrate the research and activities of the
Mobile TF,

We have discussed this information with the group over the past three years and each time a new person has come in we have explained it again. I'd say we have spent more time defending the same information to each new person who makes the same challenge over and over again.

@johnfoliot I'll also note that the referenced article has extensive
footnotes/links backing up its assertions, and so at the very least we (or
at least I) am now working with conflicting information.

I do not agree -- in fact the information in this article supports this SC. For example, we have long asserted that the actual button doesn't have to be a certain size -- that is why we said the target has to be a certain size. We were long aware of the differences in non-CSS pixels without the viewport size. We also aware of the issues when targets overlap and had originally proposed language around that.

I think the article you posted bolsters our case of this success criteria. Thank you for strengthening the need for this important criteria.

Contributor

mraccess77 commented May 12, 2017

@johnfoliot wrote/quoted " "You may be surprised to learn that current touchscreens sense only the
geometric center of a user’s contact patch, or its *centroid, *rather than
its entire area, as shown in Figure 2. So touchscreens can’t communicate
the size of a user’s contact patch to a mobile phone—.. Because a device uses only the centroid to determine what a user is tapping, the extent of the contact patch doesn’t matter

Yes, the mobile task force is aware of this - nothing in this SC indicates otherwise.

@johnfoliot wrote "I will argue that this addresses the point I tried to raise on today's
call, that asking for a 44 px square touch target is problematic from
multiple perspectives, one being that "touch targets" are not universally
square (or rectangular) per the touch screen - yes, the target will
remain/"outline"

I don't see this as being problematic. We could say that the control has a radius from the center of 44 CSS pixels which would allow for round targets -- but I don't think that adds a lot and makes it more difficult to test. The touch centroid is a single point and thus as long as the single point falls in the target area the control will recognize that touch.

@johnfoliot ""Even with iOS clearly in second place behind Android, the Apple standard
size for touch targets sticks with us, but 44 pixels is not a physical
size. And with several device operating systems on the market—and Apple
converting pixels to a device-independent measurement they call a point—we
cannot even translate 44 pixels, or points, to a single actual size."
(source:"

This is precisely why we indicate these as CSS pixels with the default viewport set. There is no way for the author to know what devices people are using so we are not able to put a physical size in. Since CSS pixels are generally consistent with the default viewport width is set it is the solution to this challenge.

@johnfoliot While I won't dismiss or denigrate the research and activities of the
Mobile TF,

We have discussed this information with the group over the past three years and each time a new person has come in we have explained it again. I'd say we have spent more time defending the same information to each new person who makes the same challenge over and over again.

@johnfoliot I'll also note that the referenced article has extensive
footnotes/links backing up its assertions, and so at the very least we (or
at least I) am now working with conflicting information.

I do not agree -- in fact the information in this article supports this SC. For example, we have long asserted that the actual button doesn't have to be a certain size -- that is why we said the target has to be a certain size. We were long aware of the differences in non-CSS pixels without the viewport size. We also aware of the issues when targets overlap and had originally proposed language around that.

I think the article you posted bolsters our case of this success criteria. Thank you for strengthening the need for this important criteria.

@Ryladog

This comment has been minimized.

Show comment
Hide comment
@Ryladog

Ryladog May 12, 2017

Ryladog commented May 12, 2017

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 16, 2017

Contributor

Several points of clarification:

  • Target does not mean size of the link or button. Can have padding or spacing around the interactive control for the touch target area
  • Increasing the touch target size does not necessarily mean larger keyboard focus indicator – see Patrick's mock up- http://codepen.io/patrickhlauke/pen/aBNREe
  • Increasing target size to 44x44 CSS pixels can be accomplished using CSS using pointer events and does not require scripting unless custom sizes are preferred for individual targets (as per James on the AG call)

There are two items that need discussion:

  1. The main concern we are hearing is around links within blocks of text. There are several options for the exception:
  • Option 1: Inline: The target is a text link in a block of text.
  • Option 2: Inline: The target is in a block of text.
  • Option 3: Inline: Targets can overlap when in a block of text where the text content can wrap.
  1. Should we drop this exception?
  • In-Page: The target is a text link where the destination is on the same page.
Contributor

kwahlbin commented May 16, 2017

Several points of clarification:

  • Target does not mean size of the link or button. Can have padding or spacing around the interactive control for the touch target area
  • Increasing the touch target size does not necessarily mean larger keyboard focus indicator – see Patrick's mock up- http://codepen.io/patrickhlauke/pen/aBNREe
  • Increasing target size to 44x44 CSS pixels can be accomplished using CSS using pointer events and does not require scripting unless custom sizes are preferred for individual targets (as per James on the AG call)

There are two items that need discussion:

  1. The main concern we are hearing is around links within blocks of text. There are several options for the exception:
  • Option 1: Inline: The target is a text link in a block of text.
  • Option 2: Inline: The target is in a block of text.
  • Option 3: Inline: Targets can overlap when in a block of text where the text content can wrap.
  1. Should we drop this exception?
  • In-Page: The target is a text link where the destination is on the same page.
@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 16, 2017

Contributor

From the AG call today, Option 2 is preferred. Please let us know if you have further concerns.

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 blocks of text.
  • Cannot be Modified: the target is controlled by the user agent and cannot be modified.
Contributor

kwahlbin commented May 16, 2017

From the AG call today, Option 2 is preferred. Please let us know if you have further concerns.

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 blocks of text.
  • Cannot be Modified: the target is controlled by the user agent and cannot be modified.
@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke May 16, 2017

Member

do we have / do we need a definition of "block of text" to go with that?

Member

patrickhlauke commented May 16, 2017

do we have / do we need a definition of "block of text" to go with that?

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower May 16, 2017

Contributor

@patrickhlauke

(assuming we have a solid definition what is a "block of text", or is it clear enough? i.e. a single short-ish line of text can become a "block" of 2 or more lines depending on viewport width)

I think a definition is needed. We can't really rely on inline or block as used in elements, since a div is a block, so putting <div><a>foobar</a></div> would be exempt, and that's obviously not the intent.

Contributor

mbgower commented May 16, 2017

@patrickhlauke

(assuming we have a solid definition what is a "block of text", or is it clear enough? i.e. a single short-ish line of text can become a "block" of 2 or more lines depending on viewport width)

I think a definition is needed. We can't really rely on inline or block as used in elements, since a div is a block, so putting <div><a>foobar</a></div> would be exempt, and that's obviously not the intent.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower May 16, 2017

Contributor

Rough draft (which definitely needs work)

Text block
A string of text, frequently enclosed in a paragraph element, of which the majority of words is typically non-interactive.
Contributor

mbgower commented May 16, 2017

Rough draft (which definitely needs work)

Text block
A string of text, frequently enclosed in a paragraph element, of which the majority of words is typically non-interactive.
@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower May 16, 2017

Contributor

draft 2, attempting to expand context and ensure a block has some non-interactive text, without making that have to be the majority of text...

Text block
A string of text enclosed within block elements such as paragraph or blockquote, which contains some non-interactive text.
Contributor

mbgower commented May 16, 2017

draft 2, attempting to expand context and ensure a block has some non-interactive text, without making that have to be the majority of text...

Text block
A string of text enclosed within block elements such as paragraph or blockquote, which contains some non-interactive text.
@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson May 16, 2017

Contributor

Blocks of text is defined in WCAG 2.0 as:

blocks of text:
more than one sentence of text

Contributor

lauracarlson commented May 16, 2017

Blocks of text is defined in WCAG 2.0 as:

blocks of text:
more than one sentence of text

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 16, 2017

Contributor

We will need to use WCAG 2.0 definition and we can change the exception to:

Inline: The target is in blocks of text.

Contributor

kwahlbin commented May 16, 2017

We will need to use WCAG 2.0 definition and we can change the exception to:

Inline: The target is in blocks of text.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 17, 2017

Contributor

Yes we need to keep the WCAG 2 definition.
Wondering about the plurality of the grammar. Shouldn't it be:

Inline: The target is in a block of text.

Contributor

DavidMacDonald commented May 17, 2017

Yes we need to keep the WCAG 2 definition.
Wondering about the plurality of the grammar. Shouldn't it be:

Inline: The target is in a block of text.

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 17, 2017

Contributor

@DavidMacDonald I had that but then was trying to use the definition term in the exception

Contributor

kwahlbin commented May 17, 2017

@DavidMacDonald I had that but then was trying to use the definition term in the exception

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep May 18, 2017

Member

I mentioned this as a result of today's meeting. Given some of the barriers continuing to persist on this proposal, I wonder if it's worth rethinking about target size requirements in terms of maximizing their potential rather than trying to specify a minimum physical size. I don't know how to word a normative criterion just yet, but in extremely plain language you'd want to say that if a control could have been bigger within the same content, then make it so. Here's a few examples:

  • If a table cell contains only a link, then the whole cell should be the target and not just the text (inspired by the article John shared above).
  • Put associated labels adjacent to controls unless it is essential they be elsewhere for greater clarity.
  • For tabs, make sure the clickable area is the entire tab, not just the text.
  • Let me click the entire accordion header and not a tiny button off to the side.

I'm sure I or others could produce more example situations.

Member

steverep commented May 18, 2017

I mentioned this as a result of today's meeting. Given some of the barriers continuing to persist on this proposal, I wonder if it's worth rethinking about target size requirements in terms of maximizing their potential rather than trying to specify a minimum physical size. I don't know how to word a normative criterion just yet, but in extremely plain language you'd want to say that if a control could have been bigger within the same content, then make it so. Here's a few examples:

  • If a table cell contains only a link, then the whole cell should be the target and not just the text (inspired by the article John shared above).
  • Put associated labels adjacent to controls unless it is essential they be elsewhere for greater clarity.
  • For tabs, make sure the clickable area is the entire tab, not just the text.
  • Let me click the entire accordion header and not a tiny button off to the side.

I'm sure I or others could produce more example situations.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot May 18, 2017

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep May 20, 2017

Member

Giving my proposal a bit more thought, maybe a criterion like this would work (using the WCAG 2.0 definition of "label"):

Each target includes any associated heading or label which does not serve more than one target, and the full extent of any container(s) for which it is the only element.

And then maybe redefine target in the glossary simply to (utilizing the existing definition for user interface component):

target: the physical area of a user interface component that accepts a click or touch for activation

I think this would certainly make a lot of unnecessarily small targets across the web much bigger, yet it inherently excludes any links within blocks of text and other points of contention. The exception for "more than one target" is meant to handle situations such as tables where multiple controls may reference a single label using aria-labeledby or similar technique.

Please critique (as if I had to ask)...

Member

steverep commented May 20, 2017

Giving my proposal a bit more thought, maybe a criterion like this would work (using the WCAG 2.0 definition of "label"):

Each target includes any associated heading or label which does not serve more than one target, and the full extent of any container(s) for which it is the only element.

And then maybe redefine target in the glossary simply to (utilizing the existing definition for user interface component):

target: the physical area of a user interface component that accepts a click or touch for activation

I think this would certainly make a lot of unnecessarily small targets across the web much bigger, yet it inherently excludes any links within blocks of text and other points of contention. The exception for "more than one target" is meant to handle situations such as tables where multiple controls may reference a single label using aria-labeledby or similar technique.

Please critique (as if I had to ask)...

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke May 20, 2017

Member

@steverep while an elegant sidestep, i would say that this is completely reliant on the assumption that the parent container is sufficiently large. sure, saying an actionable control should have an active target area as large as its container will usually result in larger target areas than if that wasn't the case, that target area can still fall below dimensions that would be most useful in tackling the problem this SC tried to solve.

the requirement to also cover any associated heading or label seems rather sweeping, and would potentially require quite a lot of recoding / would fail on a large number of current sites. note that the browser behavior of being able to click/tap a <label> and having the associated form control activate/focus is something the UA does, and is not strictly a case of the target area of the control per se being expanded automagically to cover it. and if you truly mean that the target area itself needs to encompass the header or label you'll need CSS trickery very similar to the one I proposed to somehow extend the padding of, say, a link to slip underneath/over the adjacent header/label (and this type of trickery would not be possible form form controls, where the padding is inside the actual rendered form control).

"any container(s) for which it is the only element" won't really cut it in many situations if the current implementation uses more than one element. consider for instance a vertical list/single column table, where each item/row has the name of the item, followed by a control, for instance:

<li><span>Foo bar baz</span> <button aria-label="Delete: Foo bar baz">X</button></li>

in this case, the <button> is not the only element, so this would be immediately exempted.

Member

patrickhlauke commented May 20, 2017

@steverep while an elegant sidestep, i would say that this is completely reliant on the assumption that the parent container is sufficiently large. sure, saying an actionable control should have an active target area as large as its container will usually result in larger target areas than if that wasn't the case, that target area can still fall below dimensions that would be most useful in tackling the problem this SC tried to solve.

the requirement to also cover any associated heading or label seems rather sweeping, and would potentially require quite a lot of recoding / would fail on a large number of current sites. note that the browser behavior of being able to click/tap a <label> and having the associated form control activate/focus is something the UA does, and is not strictly a case of the target area of the control per se being expanded automagically to cover it. and if you truly mean that the target area itself needs to encompass the header or label you'll need CSS trickery very similar to the one I proposed to somehow extend the padding of, say, a link to slip underneath/over the adjacent header/label (and this type of trickery would not be possible form form controls, where the padding is inside the actual rendered form control).

"any container(s) for which it is the only element" won't really cut it in many situations if the current implementation uses more than one element. consider for instance a vertical list/single column table, where each item/row has the name of the item, followed by a control, for instance:

<li><span>Foo bar baz</span> <button aria-label="Delete: Foo bar baz">X</button></li>

in this case, the <button> is not the only element, so this would be immediately exempted.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep May 21, 2017

Member

@patrickhlauke, thanks for the review.

Dimension concerns

Regarding your first point, yes I agree that the desired dimensions would certainly not be guaranteed. But the size of the dimensions is what is holding this SC back right now and resulting in too many exceptions. And from last Thursday's meeting, standard controls without styling wouldn't even make the bar. You stated:

saying an actionable control should have an active target area as large as its container will usually result in larger target areas

That's basically the goal of my proposal. Certainly there's a potential for some of those targets to then cross the 44 pixel threshold, and those that fall short may still help a number of PWDs by crossing their personal threshold or minimizing the need for zooming. Note also that a criterion formulated this way doesn't give completely unhelpful exceptions to "equivalent" or "in-page" controls as in the current wording, so there is potential to increase target size not covered by the current proposal.

Label concerns

and if you truly mean that the target area itself needs to encompass the header or label
No, that was not my intention (i.e. no CSS tricks necessary). I had two basic intentions here:

  1. To force more target area by taking advantage of the UA behavior when labels are programmatically associated I agree with you that the wording would probably need to be clarified here, so perhaps the real requirement would be adjacency to the control.
  2. To force bigger targets for components like accordion expand/collapse buttons or tab selectors. For example, I want the SC to require the panel header to be part of the target area, and not just a generic button next to it.

Container concerns

In your example:

<li><span>Foo bar baz</span> <button aria-label="Delete: Foo bar baz">X</button></li>

Yes, essentially there's an exemption here. Perhaps there's a way to at least ensure that the button would be no shorter than the <li>? In any case, consider instead the following:

<li><span>Foo bar baz</span> <button aria-label="Activate: Foo bar baz">+</button></li>

Here I would argue that the span text is part of the button's label (programmatic or not), and should be included in the target per the first requirement. Then the second kicks in so that the target needs to be the full size of the li.

Member

steverep commented May 21, 2017

@patrickhlauke, thanks for the review.

Dimension concerns

Regarding your first point, yes I agree that the desired dimensions would certainly not be guaranteed. But the size of the dimensions is what is holding this SC back right now and resulting in too many exceptions. And from last Thursday's meeting, standard controls without styling wouldn't even make the bar. You stated:

saying an actionable control should have an active target area as large as its container will usually result in larger target areas

That's basically the goal of my proposal. Certainly there's a potential for some of those targets to then cross the 44 pixel threshold, and those that fall short may still help a number of PWDs by crossing their personal threshold or minimizing the need for zooming. Note also that a criterion formulated this way doesn't give completely unhelpful exceptions to "equivalent" or "in-page" controls as in the current wording, so there is potential to increase target size not covered by the current proposal.

Label concerns

and if you truly mean that the target area itself needs to encompass the header or label
No, that was not my intention (i.e. no CSS tricks necessary). I had two basic intentions here:

  1. To force more target area by taking advantage of the UA behavior when labels are programmatically associated I agree with you that the wording would probably need to be clarified here, so perhaps the real requirement would be adjacency to the control.
  2. To force bigger targets for components like accordion expand/collapse buttons or tab selectors. For example, I want the SC to require the panel header to be part of the target area, and not just a generic button next to it.

Container concerns

In your example:

<li><span>Foo bar baz</span> <button aria-label="Delete: Foo bar baz">X</button></li>

Yes, essentially there's an exemption here. Perhaps there's a way to at least ensure that the button would be no shorter than the <li>? In any case, consider instead the following:

<li><span>Foo bar baz</span> <button aria-label="Activate: Foo bar baz">+</button></li>

Here I would argue that the span text is part of the button's label (programmatic or not), and should be included in the target per the first requirement. Then the second kicks in so that the target needs to be the full size of the li.

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin May 23, 2017

Contributor

@detlevhfischer suggested that we add another exception to the list:

Unstyled: The target is an unstyled native control

Here is what he wrote in the email:

This first sounds like a big loophole, but then, nearly all modern sites DO apply CSS of some kind to navigation links, buttons etc. - so for authors of those, the exception would not work. Legacy content would be covered. The exception would also apply to sites that use unstyled radio controls, checkboxes and selects, but in my view, this somewhat hobbled SC would still bring benefits for for the many elements (as in site navigation) that usually ARE styled.

Most importantly, it puts target size on the map as a new criterion, so many authors will try to implement it instead of looking for loopholes in the exceptions. This is better than no requirement (or an AAA requirement that will usually be ignored).

Thoughts?

Contributor

kwahlbin commented May 23, 2017

@detlevhfischer suggested that we add another exception to the list:

Unstyled: The target is an unstyled native control

Here is what he wrote in the email:

This first sounds like a big loophole, but then, nearly all modern sites DO apply CSS of some kind to navigation links, buttons etc. - so for authors of those, the exception would not work. Legacy content would be covered. The exception would also apply to sites that use unstyled radio controls, checkboxes and selects, but in my view, this somewhat hobbled SC would still bring benefits for for the many elements (as in site navigation) that usually ARE styled.

Most importantly, it puts target size on the map as a new criterion, so many authors will try to implement it instead of looking for loopholes in the exceptions. This is better than no requirement (or an AAA requirement that will usually be ignored).

Thoughts?

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer May 23, 2017

Contributor

@steverep To me, the suggestion to extend the target to the boundary of the parent element, of requiring labels to be part of target area etc. sound more like good techniques than parts of a (supposedly technology-neutral) SC.

Contributor

detlevhfischer commented May 23, 2017

@steverep To me, the suggestion to extend the target to the boundary of the parent element, of requiring labels to be part of target area etc. sound more like good techniques than parts of a (supposedly technology-neutral) SC.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk May 23, 2017

Member

An interesting example to think about is a date picker/number picker. In the native control there is a split button that has up and down arrows and they are quite small (9x9 by default in Chrome on iOS). If you zoom in they get larger but stop increasing in size around 17x17.

To have this same type of model for interaction, each would need to be 44tall, so the overall control would be 88 tall. We are covering the use of the native version, but I'm not sure if I've seen custom versions of this type of control that do something different.

A related question is whether the presence of the text field helps, in that a user can type in the value. We wouldn't allow that for keyboard access to a drop down (e.g. you don't need to open the dropdown because you can just type in the control), so I'm not thinking that we should here either.

thoughts?

datepicker

Member

awkawk commented May 23, 2017

An interesting example to think about is a date picker/number picker. In the native control there is a split button that has up and down arrows and they are quite small (9x9 by default in Chrome on iOS). If you zoom in they get larger but stop increasing in size around 17x17.

To have this same type of model for interaction, each would need to be 44tall, so the overall control would be 88 tall. We are covering the use of the native version, but I'm not sure if I've seen custom versions of this type of control that do something different.

A related question is whether the presence of the text field helps, in that a user can type in the value. We wouldn't allow that for keyboard access to a drop down (e.g. you don't need to open the dropdown because you can just type in the control), so I'm not thinking that we should here either.

thoughts?

datepicker

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep May 23, 2017

Member

Hi @detlevhfischer. I'm not sure what exactly you think is not technology neutral. Heading and label are already used in WCAG 2.0 and "label" has a very generic definition which specifically talks about not being limited to the <label> tag. As for "container", I think that could be fairly easily generalized to various technologies.

Member

steverep commented May 23, 2017

Hi @detlevhfischer. I'm not sure what exactly you think is not technology neutral. Heading and label are already used in WCAG 2.0 and "label" has a very generic definition which specifically talks about not being limited to the <label> tag. As for "container", I think that could be fairly easily generalized to various technologies.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 29, 2017

Contributor

Gregg email online comment

but even on the sites I visited — making all the navigation that large would mess up all the nav bars both vertically and horizontally. It makes the sites look horrid. and take a menu that fits on one screen and spans it across multiple. (which is bad UX) Here is an example from Alastair look at the side menu - before and after. we can do this - but I think we are just dooming 2.1 to be referred to at the unrealistic guidelines.

Perhaps we can address this with another exception, a compromise:

  • the target is part on a group of more than 10 navigation elements

The rationale being that if there are less than 10 links in the group there is not much good ui rationale for squishing links together... but when there are a lot of links then the user without a disability is being punished by the space because they have to scroll and links are not in view

Contributor

DavidMacDonald commented May 29, 2017

Gregg email online comment

but even on the sites I visited — making all the navigation that large would mess up all the nav bars both vertically and horizontally. It makes the sites look horrid. and take a menu that fits on one screen and spans it across multiple. (which is bad UX) Here is an example from Alastair look at the side menu - before and after. we can do this - but I think we are just dooming 2.1 to be referred to at the unrealistic guidelines.

Perhaps we can address this with another exception, a compromise:

  • the target is part on a group of more than 10 navigation elements

The rationale being that if there are less than 10 links in the group there is not much good ui rationale for squishing links together... but when there are a lot of links then the user without a disability is being punished by the space because they have to scroll and links are not in view

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jul 19, 2017

Contributor

@awkawk
The latest iteration of the SC text exempts native controls so that should take care of the natve date / number picker, As to accepting text inout as a conforming alternative for a popup datepicker, this has been our interpretation in testing - if the date can be specified in the text input the popup datepicker does not need to be keyboard operable (and should then better not receive keyboard focus). Your mileage my vary.

@steverep
You are right this is not necessarily HTML-specific. To me, extending the target to the parent container still feels more like a best practice / sufficient technique. We have to allow for cases where authors provide sufficient size for the interactive control on its own, choosing to not extend the boundary to the parent container.

Contributor

detlevhfischer commented Jul 19, 2017

@awkawk
The latest iteration of the SC text exempts native controls so that should take care of the natve date / number picker, As to accepting text inout as a conforming alternative for a popup datepicker, this has been our interpretation in testing - if the date can be specified in the text input the popup datepicker does not need to be keyboard operable (and should then better not receive keyboard focus). Your mileage my vary.

@steverep
You are right this is not necessarily HTML-specific. To me, extending the target to the parent container still feels more like a best practice / sufficient technique. We have to allow for cases where authors provide sufficient size for the interactive control on its own, choosing to not extend the boundary to the parent container.

@dylanb

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Aug 25, 2017

Can you change the link to the definition of a reference pixel to point to the actual section of the document that defines it https://www.w3.org/TR/CSS2/syndata.html#length-units

dylanb commented Aug 25, 2017

Can you change the link to the definition of a reference pixel to point to the actual section of the document that defines it https://www.w3.org/TR/CSS2/syndata.html#length-units

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.