WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: skip link breaks back button

for

From: Cameron Cundiff
Date: Mar 17, 2014 9:48AM

Skip links have been fixed in Chrome's rendering engine:

https://code.google.com/p/chromium/issues/detail?id=37721

> On Mar 17, 2014, at 11:32 AM, Whitney Quesenbery < <EMAIL REMOVED> > wrote:
>
> What's the point of a standard, she asks in what I assume is shared
> frustration. It's a bug. In a function that's been around since HTML1 or
> something. Why doesn't it get fixed?
>
> Whitney Quesenbery
> www.wqusability.com | @whitneyq
>
> Books:
>
> - A Web for Everyone: Designing Accessible User
> Experiences<http://rosenfeldmedia.com/books/a-web-for-everyone/>;
> - Storytelling for User
> Experience<http://www.rosenfeldmedia.com/books/storytelling>;
> - Global UX: Design and research in a connected
> world<http://www.amazon.com/gp/product/012378591X/>;
>
>
>
>
>> On Mon, Mar 17, 2014 at 11:22 AM, Jared Smith < <EMAIL REMOVED> > wrote:
>>
>> The problem is that webkit browsers have never properly supported
>> in-page links, including "skip" links. While they visually scroll,
>> they do not set keyboard focus to the target of the "skip" link, thus
>> rendering them useless to keyboard users (though screen readers
>> generally account for this bug).
>>
>> We at WebAIM implemented a simple script that would set tabindex="-1"
>> on the target of in-page links (this is necessary in webkit to set
>> focus) and then explicitly focus them with scripting. This resolved
>> the focus issues and stopped the very frequent e-mails from people
>> complaining that our "skip" link didn't work when in fact their
>> browser didn't.
>>
>> However, as noted here, I see this also causes issues with the back
>> button. In fact, it's the same issue - browsers don't set focus back
>> to the page itself when back is pressed after activating an in-page
>> link. Again, a webkit bug.
>>
>> I have just resolved this with a minor change to our script that
>> detects a change in the page hash and sets focus back to the head
>> section of the page (you can't focus the window or body in Firefox) if
>> the hash is empty (i.e., they hit the back button after an in-page
>> link). This should resolve the issue, though the best resolution would
>> be for browsers to actually support keyboard navigation properly.
>>
>> And to clarify, WCAG 2.0 does not require "skip" links. It does,
>> however, require "a mechanism" to skip repeated blocks of content.
>> Landmarks or headings certainly meet this requirement. However, modern
>> browsers do not provide navigation by these elements (something they
>> should do), thus we still recommend "skip" links as a necessary (and
>> rather intrusive and ugly) 'hack' to provide better accessibility for
>> sighted keyboard users.
>>
>> Jared Smith
>> WebAIM.org
>> >> >> > > >