WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Combobox sufficiently accessibility-supported?

for

From: Patrick H. Lauke
Date: Oct 9, 2015 2:41PM

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%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm

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