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.

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

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

Just curious what Chrome version is planned to have this fix in. Thanks!

Reverted as https://codereview.chromium.org/2609313002/ due to  http://crbug.com/675567 

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

This is a bug that busts a lot sites. VoiceOver handles it correctly.

Any idea when will this issue be fixed? 

From the Android bug (69569112):

kevinlam.sf mentioned https://webaim.org/ as an example of a broken "skip to main content" feature.

I mentioned the search box at the top of https://developer.android.com/guide/index.html as an example of pages interpreting focus in strange ways.

Can confirm. Please let us know what Chrome or Android version this will be released with. This is a problem that is affecting many users and sites with complex UI that rely on :focus to drive accessibility navigation.