JavaScript touch/pointer events research notes: screenreaders, faked mouse events, touchscreens

Over the last two years I’ve been dabbling with various aspects related to the handling of touch events and pointer events – specifically trying to determine which events are being dispatched by browsers as a result of touchscreen interactions, and what the repercussions of this are considering the increasing number of multi-input devices (such as laptops that feature both traditional keyboard/mouse/trackpad as well as a touchscreen, or nominally touch-only devices such as smartphones and tablets, but paired with a bluetooth mouse/keyboard).

One of the early outcomes of this research was an article on the Mozilla Hacks blog on the futility of trying to detect touchscreen users.

Since joining TPGi about a year ago, I expanded my experimentations to also include accessibility-specific scenarios – in particular, the intersection between touch and assistive technology (classic iOS/VoiceOver and Android/TalkBack, but also more recent additions such as JAWS 15 and its new Windows 8 touch support).

Tired of just keeping notes and tidbits of information strewn around (for instance, see the various ever-changing iterations of my talk Getting touchy – an introduction to touch and pointer events), I finally compiled a single resource for my various touch/pointer test results (though perhaps the title is now slightly inaccurate, as the results also include traditional “desktop” screenreaders used with the keyboard, mainly as a point of comparison with screenreaders on touch devices).

Although I’m still in the process of making sense of these test results as they relate to some of our tried and tested accessibility techniques, it might be interesting to just mention a few notable nuggets of information that emerged:

• even in the case of desktop keyboard users, certain combinations of browsers and screenreaders (Chrome with JAWS or NVDA, Firefox with NVDA, and all browsers tested in OS X with VoiceOver) fire “faked” mousedown and mouseup events – in addition to the regular click – when a focusable element is activated.
• when using VoiceOver on OS X, different events are fired depending on how elements are activated – for instance, activating a button with SPACE or ENTER will simply fire click, whereas CTRL+ALT+SPACE (the key combination prompted by VoiceOver) also fires the aforementioned “faked” mouse events.
• when using a screenreader on a mobile/tablet device, moving the focus (swiping left/right and using “touch explore”) will fire a JavaScript focus event – except in Firefox/Android with TalkBack, where focus is only sent as part of the series of events that follow an activation (double-tap).
• mobile screenreaders are quite liberal in firing additional blur events when an element is activated – presumably in an attempt to prevent focus-specific CSS styles to “stick” after a user tapped on an in-page link or control; careful if your code assumes blur means the user has moved away from the focusable element, as the AT focus is actually still there.
• using a desktop screenreader with a touchscreen and touch gestures (swipe left/right and using “touch explore”, similar to mobile/tablet screenreaders), none of the tested combinations of browser/AT fired a focus event when moving the focus outline to an element – focus is only sent as a result of a double-tap activation.

The results contain further interesting, often browser-specific quirks, but these will likely only be of use when debugging a particularly weird bit of behavior in your website/application. In the meantime, I hope this collection of results will be of some use. If there’s a specific combination of operating system/assistive technology/browser that you’d like to see included, get in touch.