Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 657157 Issue with skip links that are visible only on focus
Starred by 2 users Project Member Reported by dmazz...@chromium.org, Oct 18 Back to list
Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment
Reported on Twitter:

https://twitter.com/patrick_h_lauke/status/788475076719108101

Taking http://getbootstrap.com/ as an example - the site uses a classic "visually hidden, but visible on focus" skip to main content link. When focused via TalkBack, the :focus/:active class is not applied (but this would be a separate issue). However, TalkBack does announce that the skip link received focus (as can be seen by the green focus outline and the spoken text). Double-tapping, however, activates the "Awww..." link that is underneath the skip link instead (you can see that after double-tapping the green outline very briefly goes around the "Awww..." link, before then activating and following *THAT* link instead).

https://www.youtube.com/watch?time_continue=1&v=Q731KF9rpZQ

 
I can repro.

The reason this doesn't work is because when you navigate with TalkBack, it moves "accessibility focus" but doesn't move focus unless you explicitly click on an element...but then when you double-tap it simulates a click event, so that won't trigger a click on a hidden element.

I think the main reason TalkBack doesn't move focus as you navigate is because of things like text fields, where all of the interactions are different when focused.

Offhand I don't see any harm in auto-focusing links (and maybe buttons) as you explore.

I'll run it by the TalkBack team, but if they don't object I can make the change in Chrome.

By the way, if I manually trigger the :focus style with developer tools the skip link works fine, so once we make it auto-focus that will fix the bug.

Yes, it also works fine when using an actual bluetooth keyboard and TABbing to the link, making it visible, and then double-tapping.

Related, I was going to file a separate bug asking if accessibility focus could also move focus - see https://bugzilla.mozilla.org/show_bug.cgi?id=1000082 and https://twitter.com/patrick_h_lauke/status/788496138966106112
"I think the main reason TalkBack doesn't move focus as you navigate is because of things like text fields, where all of the interactions are different when focused."

Looking at iOS/VO, it seems that text entry fields, textareas, etc are special-cased, but other focusable elements like links/buttons do fire focus / receive :focus styling. Blur is fired / the :focus styles stop applying only once (accessibility) focus is moved to another focusable element (perhaps not ideal, but understandable compromise).

for parity/compatibility with iOS/VO, it would be extremely useful if TalkBack could behave the same way.
While making :focus apply will solve this specific problem, I wonder if there's also an underlying different problem though:

"The reason this doesn't work is because when you navigate with TalkBack, it moves "accessibility focus" but doesn't move focus unless you explicitly click on an element...but then when you double-tap it simulates a click event, so that won't trigger a click on a hidden element."

Why would click not be triggered on the hidden element? It did receive (accessibility) focus, and TB announced that the link can be activated by double-tapping. In keyboard scenarios, hidden / sr-only style focusable elements that have focus can be triggered, so why not in this case?

Either TB needs to NOT announce that double-tap can be used to activate, or click should be triggered even when the element is hidden, I'd have thought?
This is a longstanding issue on Android where the double-tap gesture is translated into a tap event at the center of the object with accessibility focus by the system, it's not routed through TalkBack. I passed on the feedback to that team to see if they're looking into fixing that.

I think a proper fix may have to wait for a future Android version, but we could probably provide better workarounds in the meantime.

Project Member Comment 8 by bugdroid1@chromium.org, Nov 4
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd9566093da77d9413ba61f8be1b6e03daaadf33

commit fd9566093da77d9413ba61f8be1b6e03daaadf33
Author: dmazzoni <dmazzoni@chromium.org>
Date: Fri Nov 04 20:40:02 2016

Android accessibility: automatically focus links

When setting accessibility focus to a node, auto-focus it if it's a link.
This is needed for some sites that have skip links that are only visible
when focused. It might be possible to auto-focus more than just links but
this seems the safest.

Fixing this exposed a race condition with our code to refocus the node with
accessibility focus if its location has changed - essentially when you
click on the skip link, the skip link was changing its location, causing us
to fire notifications on it because its location had changed - but that
was racing with the real change to accessibility focus from following the
skip link.

Fix this race condition by re-focusing the node with accessibility focus
after a short delay, and canceling the delayed task if accessibility
focus changes again.

Tested manually with two urls that exercise these code paths.

BUG=657157
TESTED=http://getbootstrap.com/ and http://jsfiddle.net/mev0c4dt/show/

Review-Url: https://codereview.chromium.org/2465403003
Cr-Commit-Position: refs/heads/master@{#430006}

[modify] https://crrev.com/fd9566093da77d9413ba61f8be1b6e03daaadf33/content/browser/accessibility/browser_accessibility_manager_android.cc
[modify] https://crrev.com/fd9566093da77d9413ba61f8be1b6e03daaadf33/content/public/android/java/src/org/chromium/content/browser/accessibility/BrowserAccessibilityManager.java

Status: Fixed
Just curious what Chrome version is planned to have this fix in. Thanks!
Project Member Comment 12 by bugdroid1@chromium.org, Jan 5
Labels: merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/02219589656825cba76ea57e307c1345b52bfea5

commit 02219589656825cba76ea57e307c1345b52bfea5
Author: Alexandre Elias <aelias@chromium.org>
Date: Thu Jan 05 00:22:39 2017

Revert of Android accessibility: automatically focus links (patchset #3 id:40001 of https://codereview.chromium.org/2465403003/ )

Reason for revert:
Caused scrolling bug http://crbug.com/675567

BUG=657157, 675567 

Original issue's description:
> Android accessibility: automatically focus links
>
> When setting accessibility focus to a node, auto-focus it if it's a link.
> This is needed for some sites that have skip links that are only visible
> when focused. It might be possible to auto-focus more than just links but
> this seems the safest.
>
> Fixing this exposed a race condition with our code to refocus the node with
> accessibility focus if its location has changed - essentially when you
> click on the skip link, the skip link was changing its location, causing us
> to fire notifications on it because its location had changed - but that
> was racing with the real change to accessibility focus from following the
> skip link.
>
> Fix this race condition by re-focusing the node with accessibility focus
> after a short delay, and canceling the delayed task if accessibility
> focus changes again.
>
> Tested manually with two urls that exercise these code paths.
>
> BUG=657157
> TESTED=http://getbootstrap.com/ and http://jsfiddle.net/mev0c4dt/show/
>
> Committed: https://crrev.com/fd9566093da77d9413ba61f8be1b6e03daaadf33
> Cr-Commit-Position: refs/heads/master@{#430006}

TBR=dtseng@chromium.org,sgurun@chromium.org,dmazzoni@chromium.org
BUG=657157

Review-Url: https://codereview.chromium.org/2609313002
Cr-Commit-Position: refs/heads/master@{#441248}
(cherry picked from commit 12c8f43c72337a88c60abaa36a9b0e8adbba9453)

Review-Url: https://codereview.chromium.org/2615443006 .
Cr-Commit-Position: refs/branch-heads/2924@{#674}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/02219589656825cba76ea57e307c1345b52bfea5/content/browser/accessibility/browser_accessibility_manager_android.cc
[modify] https://crrev.com/02219589656825cba76ea57e307c1345b52bfea5/content/public/android/java/src/org/chromium/content/browser/accessibility/BrowserAccessibilityManager.java

Labels: NewComponent-Accessibility NewComponent-Accessibility-Compatibility
Comment 14 by dmazz...@chromium.org, Apr 21 (4 days ago)
Components: UI>Accessibility>Compatibility
Comment 15 by dmazz...@chromium.org, Apr 21 (4 days ago)
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-compatibility -newcomponent-accessibility
Sign in to add a comment