Skip link workarounds for Chrome and IE #15714
Conversation
patrickhlauke
changed the title
Add tabindex="-1" to main #content to work around bug in Chrome (and old WebKits) and IE Update advice in accessibility section Include patch in docs CSS to suppress outline when #content is focused (particularly as Chrome sets focus as result of mouse click for tabindex="-1" elements)
| @@ -4,11 +4,16 @@ <h1 id="accessibility" class="page-header">Accessibility</h1> | |||
|
|
|||
| <h3>Skip navigation</h3> | |||
| <p>If your navigation contains many links and comes before the main content in the DOM, add a <code>Skip to main content</code> link before the navigation <a href="http://a11yproject.com/posts/skip-nav-links/">(read why)</a>. Using the <code>.sr-only</code> class will visually hide the skip link, and the <code>.sr-only-focusable</code> class will ensure that the link becomes visible once focused (for sighted keyboard users).</p> | |||
| <div class="bs-callout bs-callout-danger" id="callout-tables-striped-ie8"> | |||
| <p>Due to a long-standing <a href="https://code.google.com/p/chromium/issues/detail?id=262171" title="Chromium bug tracker - Issue 262171: Focus should cycle from named anchor">bug in Chrome</a> and Internet Explorer, you will need to make sure that the target of your skip link is at least programmatically focusable by adding <code>tabindex="-1"</code>.</p> | |||
There was a problem hiding this comment.
Perhaps make it "bugs" (plural), given that Chrome and IE have separate codebases?
Any IE bug report we can link to?
There was a problem hiding this comment.
No bug report for IE i could find, but linked to an old article which is still relevant. Also, changed from calling it a bug to shortcoming/bug :)
|
@patrickhlauke I'm just curious what you mean when it says, "Note that this bug will also affect any other in-page links your site may be using, rendering them useless for keyboard users. You may consider adding a similar stop-gap fix to all other named anchors / fragment identifiers that act as link targets." How does it affect the other in-page links? |
|
go to a page with a fragment identifier in the url, like http://getbootstrap.com/javascript/#popovers. it loads the page and scrolls to the start of the popovers section. now hit TAB on the keyboard. expected keyboard user behavior: set focus to the next focusable element from this point (e.g. the "tooltip plugin" link). only Firefox does it right. Chrome sets focus to the skip link (as it only visually scrolled the viewport to the start of popovers section, not the actual focus itself). IE just does weird things and sets focus on some link way to the start of the page. same happens if i use keyboard, select one of the links in the right-hand navigation. this is a long-standing issue in browsers. Safari/WebKit only recently patched it. Chrome/IE still don't do it right and require workarounds. |
|
Ah ok, that makes sense. Thanks for the explanation |
Skip link workarounds for Chrome and IE
tabindex="-1"to main#contentto work around bug in Chrome (and old WebKit) and IE#contentis focused (particularly as Chrome sets focus as result of mouse click fortabindex="-1"elements)