Project: chromium Issues People Development process History Sign in
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
Status: Fixed
Owner:
Closed: Apr 8
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment
Skip links do not work when using screenreader.
Reported by jyotsnak...@gmail.com, Mar 8 2010 Back to list
Chrome Version       : 5.0.316.0
URLs (if applicable) : Sample websites which contain skip link(s) - 
http://www.ibm.com/us/en/ and bbc.co.uk
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 
link.

Please provide any additional information below. Attach a screenshot if
possible.
Window- Eyes 7.01 and JAWS 11.0.576
 
Comment 1 by klink@chromium.org, Mar 9 2010
Labels: -Area-Undefined Area-UI OS-All Feature-Accessibility accessibility
Status: Untriaged
Consistent with NVDA 10.1
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 ctguil@chromium.org, Sep 11 2010
Labels: -accessibility Mstone-8
Status: Unconfirmed
Comment 5 by ctguil@chromium.org, Sep 22 2010
 Issue 37724  has been merged into this issue.
Comment 6 by ctguil@chromium.org, Sep 29 2010
Labels: -Area-UI -Mstone-8 Area-WebKit Mstone-X
Summary: Skip links do not work when using screenreader. (was: NULL)
Is this fix in? I tried it on canary build and do not see the change yet.
Comment 8 by ctguil@chromium.org, 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.
Owner: ----
Comment 10 by aslat...@gmail.com, 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.
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 dam...@gmail.com, Jan 30 2012
the WCAG (http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip) 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. 
Big accessibility problem! Should be fixed ASAP!
needs doing for mobile webkit as well. 
Comment 15 by Deleted ...@, Jul 31 2012
I experienced the same problem.
Needs a fix asap.
I've made a javaScript/jQuery work around:
Detail: http://stackoverflow.com/a/12720183
Fiddle: http://jsfiddle.net/PEDaS/1/
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
Seriously.. And label your media controls. Come on. Patience is waning
over here. :P
Comment 21 by atbe...@gmail.com, 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!
Project Member Comment 23 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -Feature-Accessibility Cr-Content Cr-UI-Accessibility
Jeez, still not fixed after all this time - shame on you. ACCESSIBILITY MATTERS
Project Member Comment 25 by bugdroid1@chromium.org, Mar 15 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=188487

------------------------------------------------------------------------
r188487 | dmazzoni@chromium.org | 2013-03-15T22:02:22.013582Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/accessibility/browser_accessibility_manager_win.cc?r1=188487&r2=188486&pathrev=188487

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

BUG= 37721 
TBR=dtseng

Review URL: https://chromiumcodereview.appspot.com/12825010
------------------------------------------------------------------------
Labels: -Mstone-X
Status: Fixed
Project Member Comment 27 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
#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.
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.

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

Thanks again!


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).
Thanks for the explanation. I filed a separate issue:  http://crbug.com/262171 , please star it for updates.

Comment 33 by rber...@gmail.com, Sep 20 2013
Up-to-date:

I hasn't been fixed yet. 
Comment 34 by bla...@gmail.com, Jul 10 2014
Still not fixed, sic.

Examples:
http://portal.mec.gov.br
http://cabotelecom.com.br
This problem affects keyboard navigation in Chrome on Mac OSX using VoiceOver as well.
Why on earth has this never been fixed?
Comment 37 by r...@newbro.org, 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?
I tested using Jaws 16 on http://accessibility.oit.ncsu.edu/training/accessibility-handbook/skip-to-main-content.html#main and it seems to work fine.
Could you provide a test page where this functionality does not work?
@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 https://dl.dropboxusercontent.com/u/573324/testcases/skiplink.html. No need to run JAWS, the issue occurs for sighted keyboard users as well.
Cc: dmazz...@chromium.org nek...@chromium.org
Status: Available
Re-opening.
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.

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 https://dl.dropboxusercontent.com/u/573324/testcases/skiplink.html
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.
Related, the issue also appears if a user navigates straight to https://dl.dropboxusercontent.com/u/573324/testcases/skiplink.html#maincontent - 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"
Ah, and it seems the "without screen reader" issue had been split into a separate bug here https://code.google.com/p/chromium/issues/detail?id=262171 ...
Labels: -Cr-Blink
Project Member Comment 46 by sheriffbot@chromium.org, Feb 9
Labels: Hotlist-Recharge-Cold
Status: Untriaged
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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: r...@nvaccess.org
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.

STR:
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.

Explanation:
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: https://github.com/nvaccess/nvda/issues/5933
skip.html
524 bytes View Download
Comment 49 Deleted
Owner: nek...@chromium.org
Status: Started
Project Member Comment 51 by bugdroid1@chromium.org, Mar 17
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559

commit ee5dac5d4335b5f4fc6bd99136d38e7a070a4559
Author: nektar <nektar@chromium.org>
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 
R=dmazzoni@chromium.org, ellyjones@chromium.org
TESTED=layout test, browser tests, manually with Voiceover

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

[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/browser/accessibility/dump_accessibility_tree_browsertest.cc
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/renderer/accessibility/blink_ax_tree_source.cc
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/shell/test_runner/web_ax_object_proxy.cc
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/shell/test_runner/web_ax_object_proxy.h
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/aria/aria-radiogroup-expected-android.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/aria/aria-radiogroup-expected-blink.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/aria/aria-radiogroup-expected-mac.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/aria/aria-radiogroup-expected-win.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/aria/aria-radiogroup.html
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/a-expected-blink.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/a.html
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/in-page-links-expected-android.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/in-page-links-expected-blink.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/in-page-links-expected-mac.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/in-page-links-expected-win.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/in-page-links.html
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/input-radio-expected-android.txt
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/input-radio-expected-blink.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/input-radio-expected-mac.txt
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/input-radio-in-menu.html
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/content/test/data/accessibility/html/input-radio.html
[add] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/LayoutTests/accessibility/in-page-link-target.html
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/Source/modules/accessibility/AXNodeObject.h
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/Source/modules/accessibility/AXObject.h
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/Source/web/WebAXObject.cpp
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/third_party/WebKit/public/web/WebAXObject.h
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/ui/accessibility/ax_enums.idl
[modify] https://crrev.com/ee5dac5d4335b5f4fc6bd99136d38e7a070a4559/ui/accessibility/ax_node_data.cc

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility
Project Member Comment 53 by bugdroid1@chromium.org, Apr 3
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ddb2190fe84221506e9ada748bbea36f45b050d

commit 9ddb2190fe84221506e9ada748bbea36f45b050d
Author: nektar <nektar@chromium.org>
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 
R=dmazzoni@chromium.org
TESTED=manual testing with file attached to bug
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/chrome/browser/resources/chromeos/chromevox/cvox2/background/live_regions_test.extjs
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/chrome/common/extensions/api/automation.idl
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/browser/accessibility/browser_accessibility_android.cc
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/browser/accessibility/browser_accessibility_win.cc
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/renderer/accessibility/blink_ax_enum_conversion.cc
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/shell/test_runner/web_ax_object_proxy.cc
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/a-name-expected-mac.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/a-name-expected-win.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/in-page-links-expected-android.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/in-page-links-expected-blink.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/in-page-links-expected-mac.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/content/test/data/accessibility/html/in-page-links-expected-win.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/LayoutTests/accessibility/clickable-expected.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/LayoutTests/accessibility/clickable.html
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/LayoutTests/accessibility/in-page-link-target.html
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/LayoutTests/accessibility/onclick-handlers.html
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/LayoutTests/accessibility/table-with-aria-role-expected.txt
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.cpp
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXNodeObject.h
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXObject.cpp
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXObject.h
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/Source/web/AssertMatchingEnums.cpp
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/third_party/WebKit/public/web/WebAXEnums.h
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/ui/accessibility/ax_enums.idl
[modify] https://crrev.com/9ddb2190fe84221506e9ada748bbea36f45b050d/ui/accessibility/platform/ax_platform_node_mac.mm

Status: Fixed
Sign in to add a comment