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

Issue 31177 link

Starred by 18 users

Issue metadata

Status: Verified
Closed: May 2010
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

"Full keyboard access" setting not respected by Chrome

Reported by, Dec 26 2009

Issue description

Mac OS X allows users to choose between two options for how the tab key affects keyboard 

1. The default, tab moves focus only between text boxes, ignoring other controls
2. Just like that on Windows and Linux, tab moves focus to the next control

Most browsers on OS X respect this setting, but allow it to be overridden. (In Safari with the 
"Press tab to highlight each item on a webpage" preference, in Firefox with the hidden config 
setting accessibility.tabfocus.)

Chrome currently ignores the setting and only allows behavior #2.

Chrome Version       : (35277)
URLs (if applicable) : Many, eg:
OS version               : 10.6.2
Behavior in Safari 3.x/4.x (if applicable): Tab key moves focus to search bar
Behavior in Firefox 3.x (if applicable): Tab key moves focus to search bar, unless config setting 
acessibility.tabfocus is modified

What steps will reproduce the problem?
1. Open System Preferences, go to Keyboard pref-pane, Keyboard Shortcuts tab. Ensure "Full 
keyboard access" (at bottom of tab) is set to "Text boxes and lists only".
2. Enter in the omnibox and press return.
3. When the page loads, press the tab key.

What is the expected result?

Keyboard focus should move to the first text box.

What happens instead?

Keyboard focus moves to the first link, as if "Full Keyboard Access" was set to "All controls"
Status: Untriaged
  Hostname: testing-119.local
  Mac OS X Version 10.5.8 (Build 9L30)
  Processor: 2 Intel 2.40 GHz
  RAM: 2048 MB

  Chrome version: 4.0.284 .0 <<< 35318>>>
  QuickTime Player: 7.6.4
  QuickTime PlayerX: <unknown>
  Flash Player: 10.0.32
Labels: Mstone-5
Status: Available
Cole - What do we want to do here?  Do we want a pref of our own?  To somehow honor 
the system value with a local override?  As the comments say, most browsers have their 
own setting to control this and don't just use the system one.
 Issue 22866  has been merged into this issue.

Comment 5 by, Jan 8 2010

BTW, I’d love this on Linux too. I never want to tab through links, always form fields.
Opera does this. However they also have spatial nav with shift+arrows.
Labels: -Area-Undefined Area-Feature
Cole and I talked about this, we decided that a reasonable solution is to just copy Safari:

Respect the global pref (text fields + lists vs. all controls) and then add a single 
checkbox in Chromium which, when set, also adds "and links" to the tab loop. This is 
off by default, since few people actually want to do that.

However, this means adding a pref, so we need Ben/Glen to buy in.

Comment 7 by, Jan 11 2010

This is one of the things that keeps me from going fully Chrome. Looking forward to 
seeing it implemented.
Labels: -Area-Feature Area-UI
Status: Assigned
I think the intent was to assign this bug and not leave it as available...
Labels: UI-Needed
Featured as item 1 in fwiw.
The Safari preference to control the tab-cycling behavior is under 'Universal Access' 
in Advanced. Most(?) screen readers need tab to go through links as well, I think while 
most other users don't. So, it seems that we need to offer a way to control the 
behavior somehow as suggested earlier. 

Labels: -UI-Needed
Status: Available
Ben and Glen are okay with adding this checkbox to UTH on Mac only.
Labels: Mstone-X wasm5kg
Status: Started

Comment 15 by, May 19 2010

Please let me opt in to this on Linux too. The Tab key is essentially useless right 
now, looping through all links on the page.
The following revision refers to this bug: 

r47807 | | 2010-05-20 09:32:36 -0700 (Thu, 20 May 2010) | 10 lines
Changed paths:

[Mac] Add a preference for the tab key cycling between just form fields, or links as well.

XIB change:
Add a checkbox bound to FilesOwner.tabsToLinks underneath the translate webpages

BUG= 31177 
TEST=Uncheck Chromium-->Preferences-->Under the Hood-->Pressing Tab... Then press Tab on and the links don't get focus; it alternates between search field and location bar.

Review URL:

Status: Fixed
Note that this new checkbox is the authoritative value for the preference. Respecting the system setting with a 
checkbox doesn't make sense because a checkbox (binary) would be representing a tertiary value: { FormsOnly | 
LinksAndForms | SystemDefault }. The checkbox is the only control that affects this tabs-to-links setting, and is 
ON by default.
Fix not in Chrome version: 6.0.413.0 r47978

Steps followed:
1) Uncheck Chromium-->Preferences-->Under the Hood --> Pressing Tab...
2) Then press Tab on 

Result: Links and other stuff get focus; it doesn't alternates between search field
and location bar.

Expected: Links don't get focus; it alternates between search field and location bar.

Comment 19 by, May 24 2010

Please explain rationale why this went into Mac only.
Fixed for reals this time (c.f.  issue 44896 ).

@towolf: It's Mac only because the UI team agreed it so. Apparently it's only available on Mac for historical 
reasons. That said, the preference's plumbing is cross-platform, so if you set webkit.webprefs.tabs_to_links to 
true in your profile's Preferences file, it should just work. Obviously not supported, and please do not ask for 
more details on how to do this in this bug; if you have questions, ask on chromium-discuss.
The following revision refers to this bug: 

r48035 | | 2010-05-24 07:37:22 -0700 (Mon, 24 May 2010) | 6 lines
Changed paths:

[Mac] Bind the tabs-to-link prefs to the right value. Novel concept.

BUG= 44896 , 31177 
TEST=The checkbox works.

Review URL:

Status: Verified
Chrome version: 6.0.415.0 r48118

Comment 23 by, May 27 2010

@rsesek, I’m overjoyed and happy with editing Preferences.

> if you set webkit.webprefs.tabs_to_links to true in
> your profile's Preferences file, it should just work.

You meant ›false‹, of course. Just in case anyone else find this information.
The current implementation of this leaves a fair bit to be desired, and it shouldn't be closed just yet... this doesn't 
actually duplicate Mac OS X behavior (buttons, radio buttons, etc are selected in addition to text boxes and lists).  
I understand this can be debated... my own preference would be for duplicating Mac OS X behavior (only 
textboxes and lists), with the initial value of the checkbox set to whatever the systemwide setting is.  I think that 
would be the least surprising for people who don't know about the check box, but I guess honest folks can 
disagree on that one... A bigger issue is that the focus frequently vanishes into the void (try tabbing while 
browsing Google Reader with tab to links set to false)... are hidden fields being tabbed to or something?  
Project Member

Comment 25 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 26 by, Mar 11 2013

Labels: -Area-UI Cr-UI

Sign in to add a comment