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);