WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: skip link breaks back button

for

From: Whitney Quesenbery
Date: Mar 17, 2014 9:32AM

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
> > > >