Focus should cycle from named anchor
Project Member Reported by dmazz...@chromium.org, Jul 19 2013
craig.hyatt reports this issue: Example url: https://dev.web.uoguelph.ca/chyatt2/: 1. Load the page 2. Hit tab to give "Skip to main content" focus 3. Hit space or enter to navigate to named anchor #main-content 4. Hit tab again and you tab from the top of the page instead of from #main-content By contrast I get the expected behavior in Firefox latest & greatest.
Jul 22 2013,
Yes - I get this too. It's an issue of accessibility for those who find using the mouse difficult, preferring to use the keyboard. All other current desktop browsers work OK.
Nov 24 2013,
Apr 2 2014,
I don't think a solution is truly accessible if it requires js. Please look into this.
Apr 2 2014,
Is it not possible to take and use or modify the webkit fix to this? This was originally a KHTML problem, which became a Webkit problem, which is now a Blink problem, but Webkit managed to fix this in trunk about a year and a half or two years ago. Is Blink so different that whatever their solution was isn't viable? Re comment #2, plenty of developers won't write a bunch of JS if it's only fixing one browser. They'll assume keyboarders will use a browser without this issue. Except, now that Opera has switched to Blink, one of the most keyboard-friendly browsers out there should now have this bug too. :( Would a Chromium fix of this bug automatically become a Blink fix?
May 1 2014,
Still experiencing the same problem in chrome 34 (34.0.1847.116 m) Any chance that this major accessibility issue will be fixed soon?
May 1 2014,
May 1 2014,
btw, to give some further context: the issue seems to have been patched in a way, but only for screenreader users https://code.google.com/p/chromium/issues/detail?id=37721 - fixing it more fundamentally for all keyboard users may make that other patch obsolete, but I'd rather see a fundamental fix like this than piece-meal fixes for special cases.
May 1 2014,
As a reference, here is the (fixed) Webkit bug https://bugs.webkit.org/show_bug.cgi?id=17450 This should be the same bug Chromium and other Blink browsers are experiencing, inherited from Webkit before the Webkit fix.
Jul 22 2014,
Hmmm, the WebKit fix seems incomplete to me. It only fixes the problem if the anchor is focusable, which wouldn't usually be the case. It seems like the desired behavior is that if the anchor itself is not focusable, the page should be focused, but if you press tab, the focus search should cycle from the position of the anchor.
Jul 22 2014,
for completeness here, another nice test page http://accessibleculture.org/research-files/in-page-links/testPage.php for variations on the theme Firefox is the browser that behaves most consistently here - each test works (once you activate an in-page link, focus goes to <body> - tested with just doing a document.activeElement - and subsequent TAB goes to the expected next link) IE11 has some issues it seems - for some tests (like the first one), focus goes to <body>, but subsequent TAB goes back to the very first link. For those variations where it does work as expected (like the second one), document.activeElement actually reports that the parent <div> or the element with tabindex="-1" actually received focus, and those are the only ones that work as expected. in short, worth copying Firefox's behavior it seems.
Jul 23 2014,
Re Comment #11 IE may be acting inconsistent because of what it considers *can* be focussed "by default" (I don't understand why or how much this differs from other browsers). "The following elements can have focus by default but are not tab stops. These elements can be set as tab stops by setting the tabIndex property to a positive integer. applet, div, frameSet, span, table, td." From http://msdn.microsoft.com/en-us/library/ie/ms534654(v=vs.85).aspx
Jul 23 2014,
the point is not whether or not elements can be focused by default. it's actually irrelevant whether or not the reported document.activeElement does indeed go to the target of the in-page link (when it's a non-focusable element) or not. what does matter is that on next tab the logical next tab stop is reached
Oct 9 2014,
The following revision refers to this bug: http://src.chromium.org/viewvc/blink?view=rev&rev=183455 ------------------------------------------------------------------ r183455 | firstname.lastname@example.org | 2014-10-09T11:30:33.871572Z Changed paths: M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/fragment-activation-focuses-target-expected.txt?r1=183455&r2=183454&pathrev=183455 M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/FrameView.cpp?r1=183455&r2=183454&pathrev=183455 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/fragment-activation-focuses-target.html?r1=183455&r2=183454&pathrev=183455 Focus unfocusable node upon reference fragment navigation Currently, when the page navigates to a non-focusable reference fragment, the currently focused element does not change. In Firefox/IE, the focus is moved to the referenced element even when this element is non-focusable. This mismatch in behavior became apparent when Blink started supporting a:focus ( https://crbug.com/388666 ). In IE/FF, clicking on <a href="#ref"> causes the link to loose focus, and therefore :focus does not get applied any more. In Chrome, however, :focus remains activated because the focus does not change. This patch changes the behavior of Blink: When the pages navigates to a reference fragment that refers to a non-focusable node, then the focus is removed from the previously focused element. See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=26907. BUG= 417636 , 262171 TEST=Tools/Scripts/run-webkit-tests fast/dom/fragment-activation-focuses-target.html Review URL: https://codereview.chromium.org/637323002 -----------------------------------------------------------------
Nov 3 2014,
The following revision refers to this bug: http://src.chromium.org/viewvc/blink?view=rev&rev=184786 ------------------------------------------------------------------ r184786 | email@example.com | 2014-11-03T10:22:13.486795Z Changed paths: M http://src.chromium.org/viewvc/blink/branches/chromium/2171/LayoutTests/fast/dom/fragment-activation-focuses-target-expected.txt?r1=184786&r2=184785&pathrev=184786 M http://src.chromium.org/viewvc/blink/branches/chromium/2171/Source/core/frame/FrameView.cpp?r1=184786&r2=184785&pathrev=184786 M http://src.chromium.org/viewvc/blink/branches/chromium/2171/LayoutTests/fast/dom/fragment-activation-focuses-target.html?r1=184786&r2=184785&pathrev=184786 Merge 183455 "Focus unfocusable node upon reference fragment nav..." > Focus unfocusable node upon reference fragment navigation > > Currently, when the page navigates to a non-focusable reference fragment, > the currently focused element does not change. In Firefox/IE, the focus is > moved to the referenced element even when this element is non-focusable. > > This mismatch in behavior became apparent when Blink started supporting > a:focus ( https://crbug.com/388666 ). In IE/FF, clicking on <a href="#ref"> > causes the link to loose focus, and therefore :focus does not get applied > any more. In Chrome, however, :focus remains activated because the focus > does not change. > > This patch changes the behavior of Blink: When the pages navigates to a > reference fragment that refers to a non-focusable node, then the focus > is removed from the previously focused element. > > See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=26907. > > BUG= 417636 , 262171 > TEST=Tools/Scripts/run-webkit-tests fast/dom/fragment-activation-focuses-target.html > > Review URL: https://codereview.chromium.org/637323002 TBRfirstname.lastname@example.org Review URL: https://codereview.chromium.org/701493002 -----------------------------------------------------------------
Feb 1 2015,
What should happen when an anchor link is clicked is defined in HTML5's "Navigating to a fragment identifier" . When the :target is not focusable, a user agent can set an internal "sequential focus navigation starting point"  to make the tabbing sequence start from there, rather than the beginning of the document.  http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid  https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
Nov 6 2015,
Sep 29 2017,
Sep 29 2017,
Sign in to add a comment