E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Chrome and Skip Links

Number of posts in this thread: 11 (In chronological order)

From: Tim Harshbarger
Date: Thu, Apr 28 2011 9:39AM
Subject: Chrome and Skip Links
No previous message | Next message →

Do skip links work in Chrome? I have one of our developers saying that he can't get skip links to work correctly within Chrome. If you click the skip link, it appears to move focus to the internal anchor on the page, but if you tab then it acts as though the keyboard focus is still on the skip link at the top of the page.

Thanks!
Tim
Tim Harshbarger
Accessibility Consultant
State Farm Insurance Companies

From: Jason Megginson
Date: Thu, Apr 28 2011 9:45AM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

What is the syntax your developer is using?

I have found that the following syntax (with tabindex="-1") works the
best:

<a href="#main">Skip to main</a>
...
<a name="main" id="main" tabindex="-1">

Jason Megginson
SSB BART Group
(O):703-637-8964
(C):703-244-7755

From: Rick Hill
Date: Thu, Apr 28 2011 9:54AM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

I don't find that this fixes the focus issue for Safari or Chrome on Mac
OS X.

Rick Hill, Web CMS Administrator
University Communications, UC Davis

From: Jadhav, Ashitosh
Date: Thu, Apr 28 2011 11:39PM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

I have worked on many sites and tabindex="-1" works fine for Mac safari.

Thanks and Regards,
Ashitosh P. Jadhav

From: Paul.Adam
Date: Fri, Apr 29 2011 7:18AM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

The example Jason gave works on Chrome for Windows. I recently competed in an accessible web design competition and did a lot of cross-browser, OS, and mobile device testing.

I found a skip link that works for Safari and Chrome on Mac. Requires JavaScript though. It will display on those browsers the visible text "Start of Content" so you may not like this but I think it could be placed off the page with CSS positioning. The live example is at http://pauljadam.com/bluemistband

<p><a href="#contentstart" id="skiplink">Skip to Content</a></p>

<p><a id="contentstart" tabindex="-1"></a></p>


<script type="text/javascript">
//<![CDATA[
var is_webkit = navigator.userAgent.toLowerCase().indexOf('webkit') > -1;
var is_opera = navigator.userAgent.toLowerCase().indexOf('opera') > -1;
if(is_webkit || is_opera)
{
var target = document.getElementById('contentstart');
target.href="#contentstart";
target.innerText="Start of Content";
target.setAttribute("tabindex" , "0");
document.getElementById('skiplink').setAttribute("onclick" , "document.getElementById('contentstart').focus();");
}
//]]>
</script>


Paul Adam
Accessibility Specialist
Center for Policy and Innovation
= EMAIL ADDRESS REMOVED =

From: Rick Hill
Date: Fri, Apr 29 2011 11:42AM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

More: tabindex isn't an attribute that can be applied to a div, so if a
skip nav is anchored to a div id, the tabindexs="-1" solution isn't
available.

W3C specs:

Elements that may receive focus should be navigated by user agents
according to the following rules:

Those elements that support the tabindex attribute and assign a positive
value to it are navigated first. Navigation proceeds from the element with
the lowest tabindex value to the element with the highest value. Values
need not be sequential nor must they begin with any particular value.
Elements that have identical tabindex values should be navigated in the
order they appear in the character stream.
Those elements that do not support the tabindex attribute or support it
and assign it a value of "0" are navigated next. These elements are
navigated in the order they appear in the character stream.
Elements that are disabled do not participate in the tabbing order.
The following elements support the tabindex attribute: A, AREA, BUTTON,
INPUT, OBJECT, SELECT, and TEXTAREA.

So, actually, the -1 is out of spec. And it would seem that tabindex=0
would do the trick. However, in Safari 5 under OSX 10.6 , neither
tabindex="-1 or tabindex="0" applied to a named anchor moves the keyboard
focus for me when I test it Š wish it would!

Rick Hill

From: Sailesh Panchang
Date: Fri, Apr 29 2011 12:57PM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

This is puzzling and raises a fundamental question: Do links that
point to content within the same Web page not work on these browsers?
What's so special about a skip nav link... apart from the fact that it
aids keyboard navigation and may or may not be visible? It is a link
with its target set to some other part of the page and should work
without a hitch without any extra JS code.
So do all same-page links fail on these browsers?
Sailesh

On 4/29/11, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> The example Jason gave works on Chrome for Windows. I recently competed in
> an accessible web design competition and did a lot of cross-browser, OS, and
> mobile device testing.
>
> I found a skip link that works for Safari and Chrome on Mac. Requires
> JavaScript though. It will display on those browsers the visible text "Start
> of Content" so you may not like this but I think it could be placed off the
> page with CSS positioning. The live example is at
> http://pauljadam.com/bluemistband
>
> <p><a href="#contentstart" id="skiplink">Skip to Content</a></p>
>
>
> <p><a id="contentstart" tabindex="-1"></a></p>
>
> 
> <script type="text/javascript">
> //<![CDATA[
> var is_webkit = navigator.userAgent.toLowerCase().indexOf('webkit') > -1;
> var is_opera = navigator.userAgent.toLowerCase().indexOf('opera') > -1;
> if(is_webkit || is_opera)
> {
> var target = document.getElementById('contentstart');
> target.href="#contentstart";
> target.innerText="Start of Content";
> target.setAttribute("tabindex" , "0");
> document.getElementById('skiplink').setAttribute("onclick" ,
> "document.getElementById('contentstart').focus();");
> }
> //]]>
> </script>
> 
>
> Paul Adam
> Accessibility Specialist
> Center for Policy and Innovation
> = EMAIL ADDRESS REMOVED =
>
>

From: Jared Smith
Date: Fri, Apr 29 2011 1:09PM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

On Fri, Apr 29, 2011 at 11:41 AM, Rick Hill < = EMAIL ADDRESS REMOVED = > wrote:
> tabindex isn't an attribute that can be applied to a div

That's according to HTML 4. ARIA overrides this rule to allow tabindex
on any element and allow values of 0 or -1
(http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_focus).

Indeed tabindex of 0 or -1 doesn't really make sense on elements that
are already keyboard navigable. I guess you could use tabindex=-1 to
remove an element from the natural taborder, though I can think of no
situation where this would be a good idea.

Of note is that these values have been supported for this behavior in
all major browsers starting with IE5.

> However, in Safari 5 under OSX 10.6 , neither
> tabindex="-1 or tabindex="0" applied to a named anchor moves the keyboard
> focus for me when I test it Š wish it would!

Yep. As Paul noted, this is a significant oversight/bug that is
currently being addressed in Safari, thus the JavaScript enhancement
that sets explicit focus to these elements (which, again, is only
possible with tabindex=-1).

Jared

From: Jared Smith
Date: Fri, Apr 29 2011 1:15PM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

On Fri, Apr 29, 2011 at 12:56 PM, Sailesh Panchang wrote:

> So do all same-page links fail on these browsers?

Yes.

More accurately, Safari (even with VoiceOver enabled) and Chrome on
Mac set visual focus (scroll the browser viewport), but do not change
the tab focus to that position in the page (if you press Tab again,
tab focus is set back to the next link after the same-page link).

Jared

From: Benjamin Hawkes-Lewis
Date: Fri, Apr 29 2011 1:27PM
Subject: Re: Chrome and Skip Links
← Previous message | Next message →

On Fri, Apr 29, 2011 at 8:11 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Apr 29, 2011 at 12:56 PM, Sailesh Panchang wrote:
>
>> So do all same-page links fail on these browsers?
>
> Yes.
>
> More accurately, Safari (even with VoiceOver enabled) and Chrome on
> Mac set visual focus (scroll the browser viewport), but do not change
> the tab focus to that position in the page (if you press Tab again,
> tab focus is set back to the next link after the same-page link).
>
> Jared

Sounds like:

https://bugs.webkit.org/show_bug.cgi?id=42661

--
Benjamin Hawkes-Lewis

From: William Lawrence
Date: Thu, May 05 2011 2:51PM
Subject: Re: Chrome and Skip Links
← Previous message | No next message

On Fri, Apr 29, 2011 at 3:25 PM, Benjamin Hawkes-Lewis
< = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Apr 29, 2011 at 8:11 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> On Fri, Apr 29, 2011 at 12:56 PM, Sailesh Panchang wrote:
>>
>>> So do all same-page links fail on these browsers?
>>
>> Yes.
>>
>> More accurately, Safari (even with VoiceOver enabled) and Chrome on
>> Mac set visual focus (scroll the browser viewport), but do not change
>> the tab focus to that position in the page (if you press Tab again,
>> tab focus is set back to the next link after the same-page link).
>>
>> Jared
>
> Sounds like:
>
> https://bugs.webkit.org/show_bug.cgi?id=42661
>

This is a failure an not a bug. Firefox and IE are the only two
browsers on the Windows platform that provide visual focus with
keyboard focus when selecting an in-page anchor.

It's a UAAG issue and not a WCAG issue.