Closed stefanFarnetani closed 8 years ago
@stefanFarnetani this is fascinating! Thanks for starting this ticket. I have a small backup of issues to look at now that I'm past a rather intense project.
In iOS, when accessibilty feature voiceOver is active, you have a accessibility Focus.
This has various names, among others it's called the virtual focus. It's the currently active element within the screen reader (VoiceOver in your case).
This information is not exposed to the browser as that would raise privacy issues. You cannot identify which element is currently focused by the screen reader.
indeed this is not exposed. further, when moving the focus with VO there are no specific events being fired other than focus
. Once a user activates something, like a button, iOS/VO will send the same sequence of events (touch events, compatibility mouse events, click
) as a "regular" iOS touchscreen interaction too. http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events - in short, there's no way to detect the difference between "touchscreen + screen reader" vs "touchscreen".
(addendum: recent versions of Android/Chrome/TalkBack don't even trigger a focus
anymore now, but do fire the same touch/mouse/click sequence when activating)
Agree. Plus the UIAccessibilityFocus
event listed in this article are only exposed to Objective-C/Swift for native apps.
It's too bad that there is no way currently to detect the virtual focus. Thanks all for the detailed informations.
In iOS, when accessibilty feature voiceOver is active, you have a accessibility Focus. With right /left swipes you can switch between elements, similar to keyboard navigation.
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIAccessibilityFocus_Protocol/index.html I don't know if it is technically possible to cath up for the mode. Even I dont't know how it is called in Android or windows phone.
But i try to help, if you ask.