New issue
Advanced search Search tips
Starred by 61 users

Issue metadata

Status: Duplicate
Merged: issue 454172
Owner: ----
Closed: Nov 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Focus should cycle from named anchor

Project Member Reported by dmazz...@chromium.org, Jul 19 2013

Issue description

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.

 
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.
I still experience the same behavior. The programmatic focus does not follow the visual focus. There are JavaScript solutions to this problem posted on the web, which consist of adding tabindex="-1" to the link destination, then adding some JavaScript to the head of the document. See for example https://gist.github.com/Zegnat/1900563#file_skiplinks.min.js but these JavaScript solutions are partial, unless you assign tabindex="-1" to every tag on the page that has an id. It would be much better to fix this problem in the browser itself, and not force web developers to hack solutions like this. 
I don't think a solution is truly accessible if it requires js. Please look into this. 
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?
Still experiencing the same problem in chrome 34 (34.0.1847.116 m)

Any chance that this major accessibility issue will be fixed soon?
Labels: Hotlist-DevRel
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.
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.
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.

Comment 10 Deleted

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.
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
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
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 9 2014

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=183455

------------------------------------------------------------------
r183455 | rob@robwu.nl | 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
-----------------------------------------------------------------
Project Member

Comment 15 by bugdroid1@chromium.org, Nov 3 2014

Labels: merge-merged-2171
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=184786

------------------------------------------------------------------
r184786 | rob@robwu.nl | 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

TBR=rob@robwu.nl

Review URL: https://codereview.chromium.org/701493002
-----------------------------------------------------------------
What should happen when an anchor link is clicked is defined in HTML5's "Navigating to a fragment identifier" [1]. When the :target is not focusable, a user agent can set an internal "sequential focus navigation starting point" [2] to make the tabbing sequence start from there, rather than the beginning of the document.

[1] http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid
[2] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
Labels: Cr-Blink-Focus
Mergedinto: 454172
Status: Duplicate
As the rest of this problem is whether Chrome/Blink implements
"sequential focus navigation point", merging to  issue 454172  to consolidate
similar issues.

I had been using chrome smooth smooth course .
but unfortunately I wear chrome long time yet also not too understand the secret code .
http://www.idwapblog.com/index.xhtml 
http://poskomp3.wapka.mobi/index.xhtml
Components: Blink>HTML>Focus
Components: -Blink>Focus

Sign in to add a comment