Re: Keeping Target Size (Enhanced)? Even with 22px?

On 21/01/2018 02:18, Repsher, Stephen J wrote:
> As the subject indicates, I’m just wondering if we are really keeping 
> Target Size (Enhanced) going to CR?  At the very least, it should be 
> renamed since it is no longer an enhanced version of anything.
> 
> The CFC covered the options at AA, but we still have open issues at AAA 
> and no consensus on their resolutions.  Since much of the discussion 
> there, and lack of resolution, was around the defensibility of 22 CSS 
> pixels as a viable measure, and that is still used in the AAA version, I 
> was assuming it was going to be dropped as well.
> 
> Personally, I’d be fine with keeping it so long as we change it to 
> simply having an exception for being within a block of text (i.e. no 22 
> by 22 CSS pixel requirement).
> 
> Sorry to be the negative Nancy…

I'd have less of a problem with a AAA that doesn't have to contort 
itself with various exemptions. However, going back to some of the 
original wording that was discussed way back at the beginning of this 
SC's journey, I'd have a counter proposal:

Success Criterion 2.5.4 Target Size (Level AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS 
pixels for coarse pointers and 22 by 22 CSS pixels for fine pointers 
[ed: both coarse and fine would need to be defined in glossary, 
borrowing the definition from CSS 4 Interaction Media Queries - 
https://drafts.csswg.org/mediaqueries-4/#valdef-media-pointer-coarse and 
https://drafts.csswg.org/mediaqueries-4/#valdef-media-pointer-fine] 
except when:

Equivalent: The target is available through an equivalent link or 
control on the same page that has a sufficiently large target size;
Inline: The target is in a sentence or block of text;


The understanding document would then go into detail about some of the 
technologies available to determine whether the user has a device with a 
coarse or fine pointer (e.g. CSS 4 Interaction Media Queries, listening 
to actual events being fired using something like 
https://github.com/ten1seven/what-input), or situations where authors 
can know for a fact that only one input modality will be present (such 
as a locked-down kiosk/atm scenario, where it's known that only a 
touchscreen will ever be used). But then understanding should also 
hammer the point home that authors should not make assumptions (e.g. 
when the page loads, the user may start using a mouse, but then may 
switch to a 'secondary' touchscreen). If in doubt, offer an explicit 
switching mechanism (similar to what Office 2013 does, allowing user to 
switch interface between mouse- and touch-optimized interface). And if 
all else fails, assume that at any point a user may switch to a coarse 
interface, and just stick with always aiming for the larger target.

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 Sunday, 21 January 2018 16:34:57 UTC