Re: viewport/browser window size does not imply presence/lack of touch input...

> Does "equivalent" allow for something the user actively enabled/disabled
(through a switch, preference, or other mechanism)?

I would think so... it says

"The target is available through an equivalent link
​*​
*or control *
​*​

We could clarify control in the understanding.

> Also, what about zooming? It's a mechanism that allows users to make
things (including target sizes) bigger, and it's built into most (all?)
current browsers...

I don't think so, its not changing CSS pixels, is it?

> it's more mature than some other things I've seen discussed on the list
(like theoretical tools that may or may not understand "common purpose" and
do something useful with it).

On that we agree.

> Breakpoints based on width/height, because they need to arrange content
best to fit the available width/height. But looking at width/height and
inferring from THAT that a particular input is present or not is not the
way to go about it. You don't test for one thing and then assume that means
another thing.

Theoretically, I agree... in actual practice, may be another thing, most
people touch small screens and on large screen use touch as a fallback to
their primary pointer ... and I know there is a narrative that "there is no
such thing as mobile" and if one of us won't consent to breakpoints, perhaps
we have to try to find another solution.

The main concern is drop downs, they open on a desktop and if there are lot
of items with large spacing they go off the page in a non scrollable
container. I know my clients are not going to accept that at AA. It may
affect the adoption of the standard. So maybe add another exception.

I indicated on the call that if there was an exception for drop down menus
which go off the screen if there is too much space, I could live with it.​

​- Exception Dropdown:​ The target is in a show/hide menu or disclosure


https://www.w3.org/TR/wai-aria-practices-1.1/#menu
https://www.w3.org/TR/wai-aria-practices-1.1/#disclosure

Or we could add as you've asked:

Exception no coarse pointer: no touchscreen or coarse pointer was detected
when using a technology supported query"

Or maybe both.





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 Tue, Jan 16, 2018 at 3:00 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 16/01/2018 19:32, David MacDonald wrote:
>
>>
>>   there's always the option ... of offering users an actual choice to
>>> switch between different sizes.
>>>
>>
>> ​I think the "Equivalent"​ exception allows that. No?
>>
>
> Does "equivalent" allow for something the user actively enabled/disabled
> (through a switch, preference, or other mechanism)?
>
> Also, what about zooming? It's a mechanism that allows users to make
> things (including target sizes) bigger, and it's built into most (all?)
> current browsers...
>
> ​> ​
>> There are large laptop/desktop-size touch displays.
>>
>> I
>> ​ would assume these would have larger targets if everything is bigger,
>> which mitigates any negative consequences of them being exempted.
>>
>
> I was meaning "large" not necessarily in terms of physical size, but CSS
> pixels. There's no correlation between a monitor (or user agent/browser
> viewport/window size) size in pixels (which is what breakpoints would be
> based on) and their actual physical size (which you can't test for, of
> course).
>
>  >
>> CSS 4 Interaction MQs, JavaScript based approaches
>>
>> How mature is this technology? I'm ok with it if it actually works ...
>>
>
> https://caniuse.com/#search=interaction%20media%20features
>
> It's more mature than some other things I've seen discussed on the list
> (like theoretical tools that may or may not understand "common purpose" and
> do something useful with it).
>
> And of course there are programmatic ways to detect the type of input the
> user is using right at this very moment, like
> https://github.com/ten1seven/what-input
>
> ... almost every site these days has breakpoints,
>>
>
> Breakpoints based on width/height, because they need to arrange content
> best to fit the available width/height. But looking at width/height and
> inferring from THAT that a particular input is present or not is not the
> way to go about it. You don't test for one thing and then assume that means
> another thing.
>
>
> 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
>
>