RE: Proposed mobile techniques for SC 3.2

While creating sufficient techniques is great, please consider validation methods as well, e.g. creating a very untestable, or subjectively testable technique creates inconsistency within the development lifecycle.  If using actual units of measure, e.g. 9MM, beyond using a ruler or electronic ruler tool, I’d like to know what people think is an efficient validation process as well.  From my own personal experience using mobile screen readers I can say that very small active areas can be challenging, but that if the item is correctly within the “focus order” it is less an issue.  For people who are not using sequential navigation of focusable elements this doesn’t help, but certainly could be a mitigating solution for small active areas onscreen.  However, again, please consider the validation technique when suggesting sufficient techniques, especially since we really won’t know if a technique is actually sufficient without an agreed upon validation method.




Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Thursday, April 16, 2015 2:45 AM
To: Alastair Campbell
Cc: GLWAI Guidelines WG org
Subject: Re: Proposed mobile techniques for SC 3.2

Thanks

This is great info.

Of course these minimum guidelines are not used for their keyboards.

but this is good info.


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

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>



On Apr 15, 2015, at 3:43 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:

Hi Gregg,

You wrote:
“But my bigger concern is that there is no platform guideline for buttons.”

AC: That isn’t true for mobile [1], Apple, Microsoft and Google [2] all specify a minimum size.

They (MS & Google at least) also try and do that in a DPI-agnostic way (Dots Per Inch) that comes out at around 9mm. Apple does so in a DPI-agonistic way they call “points”, which is the same as pixels on a 160DPI (low res) screen.

From the Android guidelines:
“On average, 48dp translate to a physical size of about 9mm (with some variability). This is comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users will be able to reliably and accurately target them with their fingers.”

Where dp = “density independent pixels”, and 1dp = 1 pixel on a  160dpi screen. Apologies for the acronyms in this area, it is a minefield.

All of the major platforms have a variety of size devices with varying sizes, so they have methods of defining sizes in device-agnostic ways.

So it is not correct to say “And even an iPhone button is indeterminate since you don’t know which iPhone it will appear on.”. Developers can specific ‘44 points’, which would be 44px on an iPhone 3GS, and 88px on an iPhone 4/5/6.

You might think that it is one thing for apps, but how does that affect the browser? Browsers also have to pick a “CSS pixel” size, so a device that has a high density screen doesn’t render everything in tiny text.

For example, I used to have an HTC One, which is a 4.7” screen with a resolution of 1080x1920 (469dpi). The default width for a website in Chrome was 360px, not 1080px, as they choose a CSS pixel size 3 times larger than the screen pixels.
Interestingly, when I used Firefox the default was different, I think 330px or something.

So when you say “Web pages for example have no idea what size they will render at.”, that is sort of true, but thanks to years of 1000px wide websites and various devices having to cope with them, the CSS pixel is a remarkably reliable way of specifying sizes.

As I mentioned  before pixels sizes are probably the best cross-platform method of sizing [3], and given these are mobile guidelines and therefore within arm’s length, you could probably set 44px as a minimum size.
(That needs some testing, I think it will be a consistent figure I’m just not sure 44px is it.)

However, I still think advising people to use the platform guidelines for minimum sizes would be the best approach, perhaps with some advice on how that translates to the web.

Kind regards,

-Alastair

1] http://www.lukew.com/ff/entry.asp?1085

2] http://developer.android.com/design/style/metrics-grids.html

3] https://alastairc.ac/2013/02/how-to-hold-your-ipad/