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

sounds very HTML Specific……

g


Gregg C Vanderheiden
greggvan@umd.edu



> On Apr 4, 2017, at 6:29 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com> wrote:
> 
> So if we add David’s last bullet suggested bullet that would be … <>
>  
> “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
> - the link or control uses the default settings of the user agent
>  
> …where px is a CSS pixel when the page is using the device ideal viewport.”
>  
>  
> KHS: Do we need the “in relation to the visible display” text main sentence? That relation doesn’t affect the pixel size, does it?
>  
>  
>  
>  
> ​​​​​* katie *
>  
> Katie Haritos-Shea 
> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
>  
> Cell: 703-371-5545 | ryladog@gmail.com <mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 | @ryladog <https://twitter.com/Ryladog>
> 
> NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.
>  
> From: David MacDonald [mailto:david100@sympatico.ca <mailto:david100@sympatico.ca>] 
> Sent: Tuesday, April 4, 2017 3:15 PM
> To: John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>>
> Cc: Patrick H. Lauke <redux@splintered.co.uk <mailto:redux@splintered.co.uk>>; w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>
> Subject: 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
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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 <mailto: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
>>  
>> CanAdapt Solutions Inc.
>> Tel:  613.235.4902 <tel:(613)%20235-4902>
>> LinkedIn 
>>  <http://www.linkedin.com/in/davidmacdonald100>
>> twitter.com/davidmacd <http://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 <mailto: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.htm <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 <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:
>>> <image002.png>
>>> [alt="Firefox button screen capture using the MeasureIt browser plugin, showing the rough measurements of the submit button"]
>>>  
>>> <image003.png>
>>>  
>>> [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 <mailto: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 <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 <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 <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
>>>> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
>>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>>> 
>>> 
>>> 
>>> 
>>>  
>>> -- 
>>> John Foliot
>>> Principal Accessibility Strategist
>>> Deque Systems Inc.
>>> john.foliot@deque.com <mailto:john.foliot@deque.com>
>>>  
>>> Advancing the mission of digital accessibility and inclusion