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

We could add another exception to address John's concern about default
buttons:

- The link or control uses the default settings of the user agent

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 3:11 PM, David MacDonald <david100@sympatico.ca>
wrote:

> 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 <(613)%20235-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
>>
>
>