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

Here's a possible compromise position which does not hinge on either the
size of the viewport or course/fine pointer sniffing, both of which have
had pretty difficult time. I agree it is a compromise for those who feel
they need bigger targets for inline links, but it addresses the comments
from WebAim and others, and it's not making it necessary to rewrite the
entire web, which the current language and other proposals have had.

===
The size of the target in relation to the visible display at the default
viewport size is at least 44px by 44px for pointer inputs except where:

- there is an alternative link or control that has at least 44px by 44px
touch target
- the information or functionality is available elsewhere on the page.
- the link is part of a block of text
- the link or control is part or a group, where each link or control is at
least 22px by 22px


where px is a CSS pixel when the page is using the device ideal viewport.


===

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, Apr 4, 2017 at 2:56 PM, John Foliot <john.foliot@deque.com> wrote:

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