Re: minimum target size for mouse

On 21/04/2016 22:07, David MacDonald wrote:
> Here's a forst crack at a rewrite of 2.5.4
>
> The size of the target in relation to the visible display at the
> default viewport size is at least:
>
> - 44px by 44px for touch events - 20px by 20px for mouse/pointer
> events (Level AA)

I'd avoid using "events" here and instead focus on the input mechanism
itself. Also, as it covers both touch and mouse, I guess the SC's title/text
itself should be amended

"2.5.4 Target Size: controls have a sufficiently large activation target
area in relation to the visible display at the default viewport size:
- 44px by 44px for touch input
- 20px by 20px for mouse/pointer input

Note: In situations where both touch and pointer/mouse input mechanisms
are present, without manual or automatic input detection, controls must 
follow the larger minimum dimensions for touch input."

and in the "Understanding" it's
probably worth reinforcing that a large target size with using a mouse 
is not problematic, whereas the inverse - a too-small target size aimed 
at mouse, but the user is on a touch input device - is always a problem.

Relating to the "visible display": how would this affect, say, 
scrolling...what happens if a control is only half scrolled into view 
(but the user CAN scroll further, i.e. it's not cut off)? Is it 
unambiguous enough that this (presumably) relates to things being fully 
reachable/scrollable into view?


> Editor note: The 20px value for mouse/pointer is a placeholder. We
> are seeking research on this and outside input. We also have to
> define the difference between a touch event and a mouse event,
> particularly in html and responsive environments. Maybe some language
> in the Understanding something like this:
>
> "On platform where there is no distinction between touch and pointer,
>  the pointer size prevails unless it can't be used for touch..." or
> something similar... edit suggestions welcome... I started a wiki
> here:
> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.4#Proposed_2.5.4

I think the angle here should be more along the lines of what I grafted 
onto the SC above...talking about inputs, multi-inputs, etc.

If we're thinking ahead to techniques, worth mentioning some techniques 
for multi-input scenarios:

- provide some form of switching mechanism [ed: Office 2013 on Windows, 
for instance, has a slightly awkward way to switch the ribbon menus 
manually between touch and mouse optimised size - see the screenshot on 
one of my slides 
http://patrickhlauke.github.io/getting-touchy-presentation/#134]

- use CSS Media Queries Level 4 Interaction Media Features [ed: but use 
them correctly/beware of false assumptions - see 
https://dev.opera.com/articles/media-features/ and my slides 
http://patrickhlauke.github.io/getting-touchy-presentation/#127 through 
to http://patrickhlauke.github.io/getting-touchy-presentation/#133]

- use script-based input type detection, such as what-input [ed. 
http://patrickhlauke.github.io/getting-touchy-presentation/#135 through 
to http://patrickhlauke.github.io/getting-touchy-presentation/#137]

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

Received on Thursday, 21 April 2016 22:55:59 UTC