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

Hi Patrick,

First, I was commenting on this:

The size of the target in relation to the visible display at the default
viewport size is at least:


   - 44 px by 44 px for pointer inputs with coarse pointing accuracy (such
      as a touchscreen)
      - 22 px by 22 px 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.

Except when a link or control:


   - is not part of the primary purpose or function of the page OR
      - has an alternative link/control whose target does meet the minimum
      size requirements

Editor's Note: this criterion borrows the distinction of "coarse" and
"fine" pointing devices from Media Queries Level 4 - Pointing Device
Quality: the pointer feature <https://www.w3.org/TR/mediaqueries-4/#pointer>
 [[!mediaqueries-4]].

(source:
https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.htm
l)


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

That is not what I was asking. Rather, given the way I initially read and
heard the requirement, I could see entities using that argument (which
*does* pass the logic test - keyboard input is an alternative to mouse and
other forms of pointer input) - that's all. Kathy pointed out that the
alternative target *also* needs to meet the 44 X 44 minimum.

To that, I remain concerned that we are in effect mandating a very specific
page element size to designers, rather than supporting a basic principle
(all targets should be large enough to activate via touch input), and I
have reservations about how much push-back we'll receive from designers
when we tell them that *EVERY* link needs to be a minimum of 44 px square.



​Next,
 (and I know you've pointed this to me before) I have
​additional
concerns over referencing a W3C Working Draft that has not yet reached
consensus and Rec status, which is where things
​ appear to​
stand with the Media Queries Working Draft (which
​seems
to be in flight as well, https://drafts.csswg.org/mediaqueries-4/#pointer).
I'll also note that this Draft has some things to note about
"accessibility" and how UI's and User Agents may deal with the concept of
course and fine pointers:

For accessibility reasons, even on devices whose pointing device can be
described as fine
<https://drafts.csswg.org/mediaqueries-4/#valdef-media-pointer-fine>, the
UA may give a value of coarse
<https://drafts.csswg.org/mediaqueries-4/#valdef-media-pointer-coarse> or
none <https://drafts.csswg.org/mediaqueries-4/#valdef-media-pointer-none> to
this media query, to indicate that the user has difficulties manipulating
the pointing device accurately or at all.


If I am to understand that correctly, the notion of "Fine" pointer may or
may-not be universally supported, which suggests to me another can of worms
if we try and build upon media-queries and pointer properties.


Finally, how will we square the issue with native inputs and other
"clickable" elements that currently do not meet the minimum? For example, I
knocked together a super-quick test with a single form submit button with
the value of "go". Two screen captures follow:
[image: Inline image 1]
[alt="Firefox button screen capture using the MeasureIt browser plugin,
showing the rough measurements of the submit button"]

[image: Inline image 2]

[alt="The same button screen captured from Chrome. The actual button size
is 21px X 31px - sizing not shown"]

The height of that submit button (Firefox 51.0.1 on Windows) is only ~20 px
high, and roughly 28-30 pixels wide, and nearly identical in size in
Chrome. Is the intent of this SC then to insist that content authors also
must over-ride native controls? That as the developer I would need to
re-style the native submit button to be larger? What about native on-screen
'virtual' keyboards - does each letter on the keyboard need to be a minimum
of 44 px square? (As James N also pointed out on the call, this would
certainly introduce horizontal scrolling, which Wayne has rightly pointed
out is one of the single largest barriers to low vision users. This feels
like an unsolvable conundrum.)

I can anticipate some real frustration there if that is the case -
designers will tell us to go jump in the lake (and frankly I'd be fairly
sympathetic to their plight).

I don't have easy answers, and I *DO* understand the problem statement and
user requirement. However my concern is that if we make WCAG overly
prescriptive we won't get increased take-up, instead we'll experience
increased push-back, which is another over-arching concern I struggle with.

JF - On the same team.

On Tue, Apr 4, 2017 at 12:14 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 04/04/2017 17:35, James Nurthen wrote:
>
>> Please find minutes at
>>
>>
>>
>> http://www.w3.org/2017/04/04-ag-minutes.html
>>
>>
> # 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.
>
> https://github.com/w3c/wcag21/issues/60#issuecomment-291565917
>
>
>
> # On the accidental activation SC
>
> > AWK: would this cover a mouse?
>
> yes
>
> > 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).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion