New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 177 users

Issue metadata

Status: Fixed
Closed: Apr 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 37721: Skip links do not work when using screenreader.

Reported by, Mar 8 2010

Issue description

Chrome Version       : 5.0.316.0
URLs (if applicable) : Sample websites which contain skip link(s) - and
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x: ok
         IE 7: ok
IE 8:

What steps will reproduce the problem?
1. Turn on JAWS or Window-Eyes.
2. Load Chrome.
3. Navigate to an URL which contains skip links or choose one of the ones 
listed above.
4. Once the page has loaded, press tab to navigate the page.
5. Tab to a skip link and press enter.

What is the expected result?
The cursor focus should be placed in the proper location. For example, if 
the skip link is to go to the main content of the page then clicking on 
the skip link should move the cursor focus to the begining of the main 
content of the page.

What happens instead?
The cursor location does not change. The cursor location stays on the skip 

Please provide any additional information below. Attach a screenshot if
Window- Eyes 7.01 and JAWS 11.0.576

Comment 1 by, Mar 9 2010

Labels: -Area-Undefined Area-UI OS-All Feature-Accessibility accessibility
Status: Untriaged

Comment 2 by, Apr 22 2010

Consistent with NVDA 10.1

Comment 3 by, Jun 22 2010

Requires scroll events to be fired on the accessible object to which the browser has scrolled. For MSAA, this is EVENT_SYSTEM_SCROLLINGSTART and EVENT_SYSTEM_SCROLLINGEND. NVDA (and probably other ATs) use EVENT_SYSTEM_SCROLLINGSTART to determine the target object for Firefox. I'm not sure why SCROLLINGEND wasn't used.

Comment 4 by, Sep 11 2010

Labels: -accessibility Mstone-8
Status: Unconfirmed

Comment 5 by, Sep 22 2010

 Issue 37724  has been merged into this issue.

Comment 6 by, Sep 29 2010

Labels: -Area-UI -Mstone-8 Area-WebKit Mstone-X
Summary: Skip links do not work when using screenreader.

Comment 7 by, Sep 29 2010

Is this fix in? I tried it on canary build and do not see the change yet.

Comment 8 by, Sep 30 2010

Status: Available
This isn't fixed just yet. I'll mark it as available for now since it's not within the scope of the M8 milestone currently.

Comment 9 by, Jul 7 2011

Owner: ----

Comment 10 by, Sep 26 2011

Note that this doesn't seem to be limited to using a screen-reader - If am am just trying to use a web-page with a keyboard and follow a skip-link in a page, focus does not go where it should compared to IE and FireFox, it stays on the "skip nav" link.

Comment 11 by, Dec 21 2011

Yes this is a general keyboard accessibility issue. The skip link's target will scroll into view but keyboard focus stays on the link itself. I've attached a basic test case containing two skip links for testing.
skip links test case.html
20.1 KB View Download

Comment 12 by, Jan 30 2012

the WCAG ( requires a mechanism for bypassing blocks of repeating content in order to be level-1 compliant. With the behaviour as-is any page requires coding javascript in order to replicate what should be a default behaviour in order to usefully meet accessibility guidelines.

Comment 13 by, Feb 27 2012

Big accessibility problem! Should be fixed ASAP!

Comment 14 by, Mar 22 2012

needs doing for mobile webkit as well.

Comment 15 by Deleted ...@, Jul 31 2012

I experienced the same problem.
Needs a fix asap.

Comment 16 by, Oct 5 2012

I've made a javaScript/jQuery work around:

Comment 17 by, Oct 5 2012

Workarounds are bad for you and the world, but thanks much for this
temporary fix. :)

Comment 18 by Deleted ...@, Oct 11 2012

Two years or more and this isn't fixed yet???

Comment 19 by Deleted ...@, Nov 30 2012

This is a terrible bug! Come on Google :D

Comment 20 by, Nov 30 2012

Seriously.. And label your media controls. Come on. Patience is waning
over here. :P

Comment 21 by, Dec 7 2012

I was testing my accessibility requirements in Chrome and couldn't figure out why this wasn't working until now. It's sad to see this has been ignored for so long.

Comment 22 by Deleted ...@, Feb 23 2013

And still this has not been dealt with! A much needed fix for all webkit users especially since the browsers based on webkit together have now surpassed IE in internet usage. Being unable to pass focus using fragmented hash links is very bad for accessibility. Once a focused link is activated(enter pressed) it should pass keyboard focus to the element now in view!

Comment 23 by, Mar 10 2013

Project Member
Labels: -Area-WebKit -Feature-Accessibility Cr-Content Cr-UI-Accessibility

Comment 24 by, Mar 13 2013

Jeez, still not fixed after all this time - shame on you. ACCESSIBILITY MATTERS

Comment 25 by, Mar 15 2013

Project Member
The following revision refers to this bug:

r188487 | | 2013-03-15T22:02:22.013582Z

Changed paths:

Fire notification when scrolling to anchor to enable skip links on Windows.

BUG= 37721 

Review URL:

Comment 26 by, Mar 20 2013

Labels: -Mstone-X
Status: Fixed

Comment 27 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 28 by, Jul 19 2013

#25 suggests this is fixed, but it doesn't seem to be in the latest Canary.  Am I looking in the wrong spot?  I'm a noob.

Comment 29 by, Jul 19 2013

It worked for me last time I tried it. Tell me what JAWS version, and give me an example url where you tried to click a skip link.

Comment 30 by, Jul 19 2013

Thanks @dmazzoni,

Perhaps I'm not being fair.  I'm not using JAWS but I do believe I'm reproducing the spirit of this issue using a keyboard only.

You can try it right now at

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.  Shall I file a separate issue?

Thanks again!

Comment 31 by, Jul 19 2013

The fix in #25 only deals with firing an accessible event, so that wouldn't affect keyboard behavior (only a screen reader's virtual cursor).

Comment 32 by, Jul 19 2013

Thanks for the explanation. I filed a separate issue: , please star it for updates.

Comment 33 by, Sep 20 2013


I hasn't been fixed yet.

Comment 34 by, Jul 10 2014

Still not fixed, sic.


Comment 35 by, Jul 14 2014

This problem affects keyboard navigation in Chrome on Mac OSX using VoiceOver as well.

Comment 36 by, Aug 21 2014

Why on earth has this never been fixed?

Comment 37 by, Feb 5 2015

This is marked as fixed? Because I still have to resort to using trick to get skip content to work properly in Chrome as of now

Comment 38 by Deleted ...@, Oct 15 2015

I can still reproduce this problem. Any timeline on when it will be fixed?

Comment 39 by, Oct 15 2015

I tested using Jaws 16 on and it seems to work fine.
Could you provide a test page where this functionality does not work?

Comment 40 by, Oct 15 2015

@nektar #39: The only reason that works is because that skip link target has a tabindex="-1" attribute. Without that it still wouldn't work properly. The average developer does not (and should not have to) know that this need to be added for an in-page link to work, so lots of skip links in the wild (that are correctly marked up)  will be broken in Chrome (and IE for that matter).

For an example of a link that doesn't work, try the first skip link in No need to run JAWS, the issue occurs for sighted keyboard users as well.

Comment 41 by, Oct 15 2015

Status: Available
The bug occurs when the <a> tag has no content and does not occur when you add content (<a name="maincontent">foo</a>), as you can successfully scroll to #main-content (the <div>).
We believe that scrolling to the main content ought to work for an empty <a name> as well.

Comment 42 by, Oct 15 2015

Just to clarify, as there seems to be some confusion here: this is not necessarily about screen readers or not. I can reproduce the problem on latest Chrome 46.0.2490.71 on Win 10 just by navigating with the keyboard, without any SR.

Also, this has nothing to do with <a> tags that are empty, or whether or not visual scrolling occurs. Taking the example that Hans provided, the process is:

1 go to
2 TAB once to set focus to the "Skip to main content" first link
3 ENTER to activate - the page scrolls down to "Your insurance company..."
4 TAB once more

expected result now is that focus is moved to the next focusable element based on the current position we moved to, i.e. "Tab stop 3". instead what happens is that focus seems to get lost at step 3, and the next TAB actually resets the focus to the first "Skip to main content" link.

Comment 43 by, Oct 15 2015

Related, the issue also appears if a user navigates straight to - the page loads and scrolls to "Your insurance company...", but on first TAB the focus goes to "Skip to main content", rather than "Tab stop 3"

Comment 44 by, Oct 15 2015

Ah, and it seems the "without screen reader" issue had been split into a separate bug here ...

Comment 45 by, Feb 9 2016

Labels: -Cr-Blink

Comment 46 by, Feb 9 2017

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit - Your friendly Sheriffbot

Comment 47 by, Feb 10 2017

This is still a problem and affects major real world use cases such as Wikipedia. (It's currently impossible to jump to sections of a Wikipedia article using the Table of Contents.) In the below test case, I use four different methods of creating a same page link. Only one of them works in Chrome at present. All four work in Firefox.

1. Start Chrome and NVDA.
2. Open the attached test case.
3. Move to the "Jump to empty A tag" link (e.g. using k to move by link).
4. Press enter.
Expected: The browse mode cursor should jump to "Empty A tag" and NVDA should report this.
Actual: It doesn't.
5. Repeat steps 3 and 4 for the "Jump to A tag with content" and "Jump to Span tag with content" links. Observe the same incorrect result.
6. Move to the "Jump to P tag with content" link.
7. Press enter.
Result (correct): The browse mode cursor jumps to "P tag with content" and NVDA reports this.

Chrome doesn't create accessibles for elements it doesn't consider as providing useful accessibility information. It is much more aggressive about this than Firefox. Unfortunately, in this case, there are no accessibles directly associated with any of these anchors. In the content cases, Chrome does fire a scrollingStart event, but it does so on the text leaf node, which IA2 clients can't/don't use (because they use IAccessibleText on the parent node).

The solution for the A tag seems simple enough: always create accessibles for A tags with a name attribute. The accessible should be "invisible" (width/height of 0), but still part of the tree.

The span case (and this applies more broadly than just spans) is a little harder. You probably don't want to force accessible creation for anything with an id attribute. However, I guess you have no way of knowing whether someone will try to scroll to a given id, particularly since it's not just existing links that can do this. The best you can do here is fire the event on the parent. Firefox doesn't create an accessible for the span case either and this is what it does in that case.

Related NVDA issue:

Comment 48 by, Feb 10 2017

524 bytes View Download

Comment 49 Deleted

Comment 50 by, Feb 25 2017

Status: Started (was: Untriaged)

Comment 51 by, Mar 17 2017

Project Member
The following revision refers to this bug:

commit ee5dac5d4335b5f4fc6bd99136d38e7a070a4559
Author: nektar <>
Date: Fri Mar 17 05:33:45 2017

Implemented full support for NSAccessibilityLinkedUIElementsAttribute.

1. In-page links now work, e.g. in the table of contents of a Wikipedia article.
2. Both native and ARIA radio buttons behave more consistently.
BUG= 37721,
TESTED=layout test, browser tests, manually with Voiceover

Cr-Commit-Position: refs/heads/master@{#457695}


Comment 52 by, Mar 27 2017

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility

Comment 53 by, Apr 3 2017

Project Member
The following revision refers to this bug:

commit 9ddb2190fe84221506e9ada748bbea36f45b050d
Author: nektar <>
Date: Mon Apr 03 20:54:23 2017

Added a quick heuristic to determine which objects are the target of in-page links and stop ignoring them for purposes of accessibility.

Windows screen readers were getting confused if the object to which an in-page link scrolled to was not an actual link target.
BUG= 37721
TESTED=manual testing with file attached to bug

Cr-Commit-Position: refs/heads/master@{#461530}


Comment 54 by, Apr 8 2017

Status: Fixed (was: Started)

Sign in to add a comment