Open
Bug 1000082
Opened 10 years ago
Updated 2 months ago
When accessibility focus is on a button or link, fire actual focus on the element, too
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
NEW
Accessibility Severity | s3 |
People
(Reporter: MarcoZ, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: access, Whiteboard: [Chrome-interop Safari-interop])
This is a request brought to our attention by Patrick Lauke from the TPG. Both VoiceOver on iOS and ChromeVox on Android set focus on buttons and links (but not text fields) when users explore or swipe to them. On the desktop, NVDA does this, too, when the virtual cursor lands on such an element. In fact, NVDA does it with all focusable elements, but because on mobile devices, setting focus to text fields would immediately bring up the keyboard, text fields are excluded. Reference/research done by Patrick: http://t.co/BObb5THOKC Benefits: 1. Interoperability with iOS/VoiceOver+Safari and Chrome, and Android/ChromeVox+Chrome, therefore providing web developers with a more consistent experience. 2. Not taking away the ability from web developers to know when an element is focused when user visits their mobile app using FF/Android or Firefox OS.
Comment 1•10 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=760972#c4
Comment 2•7 years ago
|
||
Any movement on this? It now seems that TalkBack/Chrome have changed their behavior (focusing with TalkBack does NOT fire focus event / apply :focus styles), and the same happens with Windows 10 / Narrator (on desktop and phone/tablet, using touchscreen reading gestures). https://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events - so it's only iOS/VO that does this at the moment...
Comment 3•7 years ago
|
||
Related: as part of another bug, I've floated the idea to Chrome/TalkBack team https://bugs.chromium.org/p/chromium/issues/detail?id=657157&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=
Comment 4•7 years ago
|
||
At a very high level, the request here is probably "cursor/focus should follow accessibility focus (with slight exceptions/special-casing for touch devices where a 'real' focus on a text entry field or similar triggers special behavior/interactions like on-screen keyboards)" (this would not only apply to Android/TalkBack/Firefox, but possibly more fundamentally on desktop etc as well)
Comment 5•7 years ago
|
||
Related, posted a feature request for Narrator/Windows https://microsoftaccessibility.uservoice.com/forums/307429-microsoft-accessibility-feedback/suggestions/16717318-focusable-elements-should-fire-focus-event-recei
Reporter | ||
Comment 6•6 years ago
|
||
Eitan, will our new implementations have any effect on this bug?
Flags: needinfo?(eitan)
Comment 7•6 years ago
|
||
No. At least not the first part. Regardless, this is not how Chrome/Talkback interoperate these days. Maybe this was the case with ChromeVox, I don't know. Focus does follow the accessibility focus. That might be different in iOS, but I think our implementation should be closer to Chrome/WebView. I'm tempted to close this as WONTFIX.
Flags: needinfo?(eitan)
Reporter | ||
Comment 8•6 years ago
|
||
Close at your discretion. :)
Comment 9•6 years ago
|
||
On second thought, and after reading the Chrome bug, I think we can do this for non-editable elements. So it might be worth leaving open.
Updated•4 years ago
|
OS: All → Android
Hardware: ARM → All
Updated•4 years ago
|
Summary: [AccessFu] When virtual focus is on a button or link, fire actual focus on the element, too → When accessibility focus is on a button or link, fire actual focus on the element, too
Updated•4 years ago
|
Priority: -- → P3
Updated•1 year ago
|
Severity: normal → S3
Updated•2 months ago
|
Accessibility Severity: --- → s3
You need to log in
before you can comment on or make changes to this bug.
Description
•