RE: Comments on the discussion about target size and accidental activation (was Re: Minutes: AGWG meeting April 4, 2017)

Hi all,

Andrew asked for an example of “Id” footnotes. In addition to the footnote number being a link to take you back up to the text/content, there can be really short links within the footnote, such as a number (for a statutes or other content) and even just the word “id”. The link within the footnote generally takes you to another, totally different document.

Screen shots don’t really work, so I’ve mocked up what that might look like. The links are simulated by blue underlined text.

And yes, there are literally hundreds of footnotes in this document.

201     Id. at 188.
202     Id.
203     Id. at 165, 232-33.

I hope that helps.


-----Original Message-----
From: Patrick H. Lauke []
Sent: Tuesday, April 04, 2017 12:14 PM
Subject: Comments on the discussion about target size and accidental activation (was Re: Minutes: AGWG meeting April 4, 2017)

On 04/04/2017 17:35, James Nurthen wrote:

> Please find minutes at






# On the target size SC discussion:

> JF: havea requirement that links need to be keyboard accessible - is that an alternative method

this basically assumes that all touchscreen users also have a keyboard with them? or rather, that it's ok for designers to make their targets too small for unambiguous use because users that have a problem should be using a keyboard instead?

> DMD: this came out of the mobile TF. Trying to fix that people on small screens - that was the primary reason as i understand it

Incorrect. We are trying to fix the problem of people that have mobility challenges (shaky hands, for instance) in accurately targetting links/controls (using their finger on a touchscreen, using a mouse, etc).

> DMD: what we are now proposing is to adopt the apple mobile SC and port those to desktop environments

Incorrect. We are trying to port the apple/google/microsoft proposed minimum target sizes to all touchscreen environments (regardless of "mobile", "tablet", "phablet", "touch-enabled laptop", "desktop with large touchscreen"), and to expand this (with a smaller size

requirement) to also cover traditional mouse/trackpad users who have similar problems in accurately hitting activation targets.

>  this is a perfect example( footnotes) where little tiny lines would have to be much  > bigger. Most sites would fail this right now. We would be talking abotu a major  > rewite of the entire web. Would be lots of buy-in for small screens but lots of  > orgs wont want this on desktop environments

Orgs that want to comply to 2.1 should be prepared to put in extra work to make sure they pass new SCs. If the argument is mainly "it's too much work for too little gain" then I'd rather see this SC moved to AAA but kept intact.

> <David-MacDonald> The compromise would be to use mobile break points.

Small screens have large target requirements.

Small viewport is not an indicator of "user has a touchscreen". It's a naive fallacy, and one that I will absolutely oppose being enshrined in any official guideline. If I'm a touch user, I'll have the same problems activating targets that are too small whether I'm on a small screen, or a large screen, or on the same large screen with my browser resized to be smaller than full-screen.

# On the accidental activation SC

> AWK: would this cover a mouse?


> greg: I don't think the wording does that  > ... way i read the current wording - if I use the standard click event i would not  > comply as I have not satisifed that

You would ibe, since that would satisfy the "platform's generic activation/click event" part of the first bullet?

> if the generic platform one isn't on up event and haven't done it on up event then need to do one of the other techniques [...]  > greg: can't be sure we are running on a browser where activation is on up.


> you cannot be sure there is not a browser where you can't do it on the down event

the requirement here is not "activate on the up event", it's "no accidental activation". If you're sticking to using click event, and the browser for whatever reason fires it on the down, rather than the up (which, to my knowledge, is not the case in current browsers), then you're still satisfying the first bullet, and sticking to the browser conventions. it's then a problem of the UA, not of the author's code, if the *browser* somehow didn't implement mechanisms that prevents users from accidentally activating things (all browsers to my knowledge do this today).



Patrick H. Lauke<> |  |

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 4 April 2017 19:40:13 UTC