WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Combobox sufficiently accessibility-supported?

for

From: Bryan Garaventa
Date: Oct 9, 2015 5:52PM

> It is conceivable that this could be made to work though, with the focus nominally remaining on the combobox' input, but VoiceOver/TalkBack allowing the
> user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next
> item in the sequential focus order.

That is true, and would be helpful if implemented. It doesn't say anything about this in the spec though, so achieving consensus on how it should work is debatable.

> Maybe nitpicking here, but: no, you can't detect a touchscreen
> https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/.
> The closest you can come to, nowadays, is detecting whether or not a browser supports touch events (which says nothing about whether or not a touchscreen
> is actually present, though most browsers pretend not to understand touch events in the absence of a touchscreen when they first start up) or, using pointer
> events, you can query navigator.maxTouchPoints
> http://www.w3.org/TR/pointerevents/#extensions-to-the-navigator-interface
> - while this is more accurate, it still doesn't account for multi-input situations (such as a Microsoft Surface) where a user may be using a mouse or
> keyboard despite the presence of a touchscreen.

Yes, I know, the "if ('ontouchstart' in window || navigator.maxTouchPoints > 0 || navigator.msMaxTouchPoints > 0)" hack is the method being used to identify the presence of a browser that supports it within the module, which beyond some basic onFocus/onBlur modification and offscreen text changing, does little else to change the underlying functionality of the widget. It is however sufficient until something better comes along as a more reliable and spec-compliant method becomes available by the OS/Browser venders.

> The CSS 4 Interaction Media Features
> (pointer/hover/any-pointer/any-hover) are similarly flawed when it comes to multi-input scenarios
> https://dev.opera.com/articles/media-features/

Yes, we live in exciting times...

> If your implication, however, was that we can detect touchscreen devices by looking at the viewport size, I'd warn that this is simply bad practice (and
> in an increasingly diverse ecosystem, where you can have desktops/laptops with touchscreens, or users of large screens that simply make their browser small
> or enlarged/zoomed in) - don't rely on one thing (in this case, viewport width) to deduce something else (whether or not it's a touchscreen device).

No, that is not my implication. If you use the ontouchstart hack it is then possible to compare/combine this with the browsers being used within different devices as needed such as with the useragent string to detect when the touch device is a phone or tablet. The result simply being a slight UI modification as needed if successful.

> Ah, looking at the demo, you're actually doing browser sniffing. This is, of course, also a discouraged practice.
> https://developer.mozilla.org/en-US/docs/Browser_detection_using_the_user_agent

As the same webpage you referenced states:
"But browsers and standards are not perfect, and there are still some edge cases where detecting the browser is needed."

Until something better becomes available by the OS/browser venders, this method works for the time being.

As a note, the ARIA Combobox module doesn't do any browser sniffing, this is added separately to tweak the UI in combo with the setup.js code as needed.
E.G http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/js/setup.js

Specifically, where it states:

// Set a default list option display size for touch screens, 3 for phones, 5 for tablets
myAuthorCombobox.setSize(isPhone ? 3 : 5);



-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Patrick H. Lauke
Sent: Friday, October 09, 2015 1:42 PM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Combobox sufficiently accessibility-supported?

On 09/10/2015 19:06, Bryan Garaventa wrote:
>> Certainly for touchscreen/AT users (e.g. mobile phones/tablets),
>> comboboxes can present considerable problems, such as not being able
>> to actually navigate to any of the suggestions. This is particularly true for the ones that rely purely on activedescendant, as that - from my cursory testing a while ago - is not supported in iOS/VoiceOver nor Android/TalkBack.
>
> This is true, and likely never will be since the element that is touched is the one that is being interfaced with by the AT, and that is what aria-activedescendant will always convey.

It is conceivable that this could be made to work though, with the focus nominally remaining on the combobox' input, but VoiceOver/TalkBack allowing the user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next item in the sequential focus order.

> It is possible though, to use responsive design to detect touch screen
> devices

Maybe nitpicking here, but: no, you can't detect a touchscreen https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/.
The closest you can come to, nowadays, is detecting whether or not a browser supports touch events (which says nothing about whether or not a touchscreen is actually present, though most browsers pretend not to understand touch events in the absence of a touchscreen when they first start up) or, using pointer events, you can query navigator.maxTouchPoints http://www.w3.org/TR/pointerevents/#extensions-to-the-navigator-interface - while this is more accurate, it still doesn't account for multi-input situations (such as a Microsoft Surface) where a user may be using a mouse or keyboard despite the presence of a touchscreen.

The CSS 4 Interaction Media Features
(pointer/hover/any-pointer/any-hover) are similarly flawed when it comes to multi-input scenarios https://dev.opera.com/articles/media-features/

If your implication, however, was that we can detect touchscreen devices by looking at the viewport size, I'd warn that this is simply bad practice (and in an increasingly diverse ecosystem, where you can have desktops/laptops with touchscreens, or users of large screens that simply make their browser small or enlarged/zoomed in) - don't rely on one thing (in this case, viewport width) to deduce something else (whether or not it's a touchscreen device).

> and adjust the behavior accordingly so that Listboxes with referenced items aren't lost, and to detect the sizing of such screens to dynamically adjust the number of listed items.
>
> An example of this can be tested at
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Combob
> oxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.h
> tm

Ah, looking at the demo, you're actually doing browser sniffing. This is, of course, also a discouraged practice.
https://developer.mozilla.org/en-US/docs/Browser_detection_using_the_user_agent

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