Search code examples
javascriptiosaccessibilityvoiceoverdom-events

What dom events are fired by flick left on Voiceover?


Using Voiceover on a iPhone or iPad, you flick left or right (one-finger swipe left or right) to move from element to element on a website. What we want is, when someone gets to the end of a long side nav menu and flicks left to move onwards, the menu closes. For keyboard navigation, this happens because the last element in the menu has an on-keydown that checks if someone used the tab key to move on, and if so calls "closeMenu".

What dom event can we listen to so that we know when someone using swipe (on phone/tablet) or Control-Option-Left arrow (desktop equivalent) wants to move on from the menu?

Does the iPhone report a flick as keydown of Ctrl-Alt-arrow? It doesn't seem to report it as touchstart or mousedown or keydown. According to this page by Dylan Barrell (http://webcache.googleusercontent.com/search?q=cache:jyTfjSFuLbEJ:unobfuscated.blogspot.com/2013/05/event-handlers-and-screen-readers.html+&cd=4&hl=en&ct=clnk&gl=us) Ctrl-Option-Space is reported as "mousedown mouseup click" but he doesn't mention the Voiceover key combo plus left or right arrow.


Solution

  • You should get onFocus and onBlur events. At least that's what my simple test case shows. I have an element with a 'focus' CSS selector and that CSS is applied when I flick to that element. However, I'm not sure you should do what you're proposing.

    When flicking with VoiceOver, you are essentially exploring the DOM. You are not interacting with the page. It's the same as using JAWS and the virtual PC cursor. You can arrow up/down to navigate through the DOM tree (analogous to flicking left/right in VO) but you are not interacting with the page. Once you get to the DOM element you're interested in, then you can interact with the page (double tap with VO or enter/space with JAWS).

    What you're proposing is a middle ground. You want the VO user to navigate the DOM but when they move past one of the elements, you want that to be interpreted as interacting with the page and closing the menu.

    That could be confusing for typical VoiceOver user. You'd have to do some usability tests with real VoiceOver users.