Re: Proposed mobile techniques for SC 3.2

All of the touch discusssion on size and space should also consider the touch and explore or touch to read of items that may not be links or buttons but checkboxes and text field as well. I've recently run into a testing situation where a basic web checkbox is presented on an iPad Mini 2. The target size for the check box is is extremely small. Focus is not consistently put on the checkbox but rather the label is read instead. Since the iPad and Android do different things with the checkbox and labeling, they may not have the same associativity as found on larger devices (PCs) with their respective screen readers and keyboard navigation. 
This is a very important thing to get right and I appreciate everyone's insight and conversations. Regards. Alan




Sent from my Samsung Galaxy Tab®4

-------- Original message --------
From: Alastair Campbell <acampbell@nomensa.com> 
Date:04/16/2015  4:36 AM  (GMT-05:00) 
To: Gregg Vanderheiden <gregg@raisingthefloor.org> 
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org> 
Subject: Re: Proposed mobile techniques for SC 3.2 

Gregg wrote:
"Of course these minimum guidelines are not used for their keyboards.”

True, but they have some pretty good algorithms for working out which key you meant to press, automated correction or word suggestion  and in some cases alternative keyboards or voice input.

"It still seems strange to me that we are suggesting that interfaces should be at least 9mm to accommodate people with physical disabilities….. "

Circling back to the original question (which I see has been updated already [1]), in a web context I think you could specify 44px x 44px (in CSS pixels, not device pixels), but I admit that needs some testing.

Perhaps a line could be added underneath the best-practices to say something like “For web content on mobile devices 9mm is approximately 44px in CSS units.” It is not practical for a web developer to know the sizing of 9mm across devices, and often triggers the kind of discussion we’ve just had!

If you meant that it is odd we specify a size for people with disabilities that is the same as the general population, then I would perhaps phrase the size point as:
"Ensuring that touch targets are at least the size specified in the mobile platform guidelines."

Then explain that the platform guidelines generally specify 9mm high by 9mm wide, which translates to 44px by 44px.

In the context of a browser, they have already had to make the decision about how big is big enough, and that is the size of pixels.

I’m still not convinced about second best practice:
"Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space."

Although it is technically true, the times where it matters are when you have navigation bars or buttons that are visually together.

If you have two buttons that are visually next to each other with no gap, should the developer shrink the size of the hit area so it is less than the visual appearance? 

I think that would be counter productive. If the user touches the interface and nothing happens because they went in the gap, that is probably worse than the UI guessing which option they meant.

Kind regards,

-Alastair

1]http://w3c.github.io/Mobile-A11y-TF-Note/#touch-target-size-and-spacing