Re: Inline links with large-enough activation (touch) target (rough idea)

We should add this question and the Patrick's responses to the SC in an
"Working Group Notes" section.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

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 Mon, Nov 14, 2016 at 9:27 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

>
>
> On 14/11/2016 14:52, David MacDonald wrote:
>
>> I presented the touch target size proposal to the Toronto accessibility
>> group... their response regarding the 48 vs 24 coarse vs fine point
>> requirements was
>>
>> "How do we know when when we should serve up one vs another. Seems like
>> a difficult thin."g to sniff accurately for give the wide rage of
>> devices..."
>>
>> We'll need to solve that I think...
>>
>
> Assuming this would then be part of understanding/techniques again,
> following approaches come to mind:
>
> - seeing that it's not possible to reliably detect a touchscreen, and -
> particularly in multi-input scenarios - it's not easy to know for sure even
> if a touchscreen can be detected whether or not a user will actually use
> that or some other input device instead: unless you are
> designing/developing for a closed system where you know for a fact which
> type of input(s) will be available (e.g. embedded system only to be used
> for touchscreen-enabled point of sales terminals, or a system for content
> only to be used on an ATM style device without touchscreen but with
> physical keyboard-like buttons on the side of the display), developers
> should assume that at some point or other their content/app will be used on
> a touchscreen; see also "when any [...] machine could have a touch
> interface, [...] proceed as if they all do" https://medium.com/let-me-repo
> st-that-for-you-zeldman/jason-grigsby-on-design-beyond-
> touch-e862b699d426#.9go7knctr
>
> - offer the user a mechanism as part of the app/site UI to switch between
> "mouse-friendly" and "touch-friendly" interface. this is the approach that,
> for instance, Microsoft Office 2013 uses (See slide 137
> https://patrickhlauke.github.io/getting-touchy-presentation/#137)
>
> - use CSS Media Queries Level 4's "any-pointer" feature to ascertain if a
> coarse pointer is present (indicating at least one of the inputs available
> to the user is coarse, e.g. a touchscreen) https://drafts.csswg.org/media
> queries-4/ (note my article on using CSS MQ4 detection carefully
> https://dev.opera.com/articles/media-features/, as well as recent
> discussion on changing the spec to drop the idea of "primary" vs "rare"
> inputs https://github.com/w3c/csswg-drafts/issues/690)
>
> - use third-party libraries like https://github.com/ten1seven/what-input
> to detect as soon as a user switches between using a mouse/touchscreen -
> then it's up to the app/site to decide what to do (immediately switch out
> the interface to coarse or fine pointer optimized? present the user with a
> dialog asking if they now want to switch to the type of input that they
> just used? etc)
>
> 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
>
>