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

Done. Also added a note about the inline link technique to the 
Techniques part

https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m2.md

P

On 14/11/2016 15:55, David MacDonald wrote:
> 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 <http://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 <mailto: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-repost-that-for-you-zeldman/jason-grigsby-on-design-beyond-touch-e862b699d426#.9go7knctr
>     <https://medium.com/let-me-repost-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
>     <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/mediaqueries-4/
>     <https://drafts.csswg.org/mediaqueries-4/> (note my article on using
>     CSS MQ4 detection carefully
>     https://dev.opera.com/articles/media-features/
>     <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
>     <https://github.com/w3c/csswg-drafts/issues/690>)
>
>     - use third-party libraries like
>     https://github.com/ten1seven/what-input
>     <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 <http://www.splintered.co.uk> |
>     https://github.com/patrickhlauke <https://github.com/patrickhlauke>
>     http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> |
>     http://redux.deviantart.com
>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

-- 
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 Monday, 14 November 2016 15:13:29 UTC