E-mail List Archives

Search E-mail List Archives for

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

From: Gijs Veyfeyken
Date: Mon, Mar 17 2014 3:32AM
Subject: skip link breaks back button
No previous message | Next message →

Hi,

When implementing a fix to make skip links work in all browsers, as described in Terril Thompson's article (http://terrillthompson.com/blog/161) and used on webaim.org as well, we noticed the back button no longer works.

Any idea's on how to make both play nicely together?

Kind regards,

Gijs

---
Gijs Veyfeyken
AnySurfer - towards an accessible internet
A project of Blindenzorg Licht en Liefde vzw
Kunstlaan 24 box 21
1000 Brussels
Belgium

From: Thaddeus Cambron
Date: Mon, Mar 17 2014 3:39AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

Which is better. Skip links or landmarks
On Mar 17, 2014 2:33 AM, "Gijs Veyfeyken" < = EMAIL ADDRESS REMOVED = > wrote:

> Hi,
>
> When implementing a fix to make skip links work in all browsers, as
> described in Terril Thompson's article (
> http://terrillthompson.com/blog/161) and used on webaim.org as well, we
> noticed the back button no longer works.
>
> Any idea's on how to make both play nicely together?
>
> Kind regards,
>
> Gijs
>
> ---
> Gijs Veyfeyken
> AnySurfer - towards an accessible internet
> A project of Blindenzorg Licht en Liefde vzw
> Kunstlaan 24 box 21
> 1000 Brussels
> Belgium
>
>
>
>
> > > >

From: Patrick H. Lauke
Date: Mon, Mar 17 2014 3:52AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

On 17/03/2014 09:39, Thaddeus Cambron wrote:
> Which is better. Skip links or landmarks

Landmarks are only of use to users of AT like screenreaders.
Keyboard-only users without AT cannot take advantage of them (unless
they employ some form of additional extension/plugin such as
http://blog.paciellogroup.com/2013/07/enabling-landmark-based-keyboard-navigation-in-firefox/).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Alastair Campbell
Date: Mon, Mar 17 2014 4:40AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

I'm not sure I know what you mean by doesn't work?

If I use the webaim example, selecting back once doesn't appear to do
anything because you followed a link within the page. Selecting it again
does take you back a page.

Theoretically you could remove that action from the browsers history so
that selecting back takes you to the previous page (I think, I've not
messed with the browser history in JS before). However, I have a feeling
that would create new problems.

Perhaps selecting the skip link could alter the history to include the skip
link as that page? So once you've followed a skip link you'd have:

1. The last page (e.g. google.com search results)
2. The skip link (e.g. example.com/#skiplink)
3. The new location on the page (e.g. example.com/#targetOfSkipLink)

Then pressing back would (well, might, I haven't tested it) take you to the
top of the page, where you were before.

-Alastair

From: Patrick H. Lauke
Date: Mon, Mar 17 2014 4:50AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

On 17/03/2014 10:40, Alastair Campbell wrote:
> I'm not sure I know what you mean by doesn't work?
>
> If I use the webaim example, selecting back once doesn't appear to do
> anything because you followed a link within the page. Selecting it again
> does take you back a page.

If you hit back the first time, it should take you back to the top of
the document.

See for instance http://webaim.org/articles/visual/colorblind, hit the
"Designing for Color-blindness" in-page link, then hit back - normally,
this should take you back to the top, where you activated the in-page
link, but it doesn't.

I have some half-formed solution in my head involving the history API
(basically, once you hit an "enhanced" in-page link, store the current
location within the document, and if user goes back in history/hits
back, run additional script that does the exact same thing -
programmatically setting focus - in reverse to take you back to where
you clicked the in-page link).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Stanzel, Susan - FSA, Kansas City, MO
Date: Mon, Mar 17 2014 6:56AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

Good morning Listers,

I had been under the impression we could stop using skip links, but I gather for keyboard only users they are still necessary. Is this correct?

Susie Stanzel

From: Hewitt,Susan (DSHS)
Date: Mon, Mar 17 2014 7:13AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

I do not believe WCAG 2.0 AA includes skip links/bypass criterion as A does. But I don't think this is a good reason to abandon them. WebAIMs last motor disability user survey had roughly 60% saying skip links are somewhat to very useful (surprisingly they didn't find links that become visible on focus that useful.) Low vision users also found them useful. (http://webaim.org/projects/motordisabilitysurvey/)

For this reason, and considering how easy it is to use them without a sacrifice of functionality or visual design, why we should stop using them? Until it becomes easier for non-mouse users to take advantage of ARIA (yes there are means for them to do so now but it's going to take education and outreach to make this known,) why deprive anyone of something that's potentially beneficial?

Susan Hewitt
EIR Accessibility Coordinator
Texas Department of State Health Services
= EMAIL ADDRESS REMOVED = | 512-776-2913

From: Whitney Quesenbery
Date: Mon, Mar 17 2014 7:44AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

Slight digression into another challenge of navigating content-rich pages:

Although not the same as skip links, an "on this page" menu of links is
very helpful for many users, improving the usability for everyone.

I've done usability testing on several large sites that use them, working
with diverse people interacting with the site in a wide variety of ways,
and they have always worked, when designed appropriately.

* On one site, the pages were structured with good headings. A screen
reader user quickly found that he could jump to the third <H> on the page
to reach them. He was one of the most efficient (fastest) at finding
specific information on a large page, because he jumped directly to the
correct section without scanning other text.

* On another site, we saw the "On this page" (OTP) links used differently
by frequent and new users of the site: new users engaged in typical
F-pattern reading, jumping from heading to heading (visually or
non-visually) to make sure they had seen all of the info on the page; those
who used the site frequently used the OTP menu to jump directly to the
section they needed.

We derived some design heuristics. The OTP menu:

* Had to be near the top of the page, usually on the right, in a visually
distinct presentation.

* They had to be part of the semantic structure (Headings, ARIA)

* They had to be in a consistent place in the visual and semantic
presentation on all pages.

* They could not come before, and interrupt, the visual reading pattern,
though they could come before the main content in the semantic code.


This is a good example of a way to solve both a usability and accessibility
problem (navigating a large page) with a universal design.


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 9:13 AM, Hewitt,Susan (DSHS) <
= EMAIL ADDRESS REMOVED = > wrote:

> I do not believe WCAG 2.0 AA includes skip links/bypass criterion as A
> does. But I don't think this is a good reason to abandon them. WebAIMs last
> motor disability user survey had roughly 60% saying skip links are somewhat
> to very useful (surprisingly they didn't find links that become visible on
> focus that useful.) Low vision users also found them useful. (
> http://webaim.org/projects/motordisabilitysurvey/)
>
> For this reason, and considering how easy it is to use them without a
> sacrifice of functionality or visual design, why we should stop using them?
> Until it becomes easier for non-mouse users to take advantage of ARIA (yes
> there are means for them to do so now but it's going to take education and
> outreach to make this known,) why deprive anyone of something that's
> potentially beneficial?
>
> Susan Hewitt
> EIR Accessibility Coordinator
> Texas Department of State Health Services
> = EMAIL ADDRESS REMOVED = | 512-776-2913
>
>
>
>

From: deborah.kaplan
Date: Mon, Mar 17 2014 8:12AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

A survey among our user base showed that the primary users of
skip links were magnification users, so that they didn't have to
drag around the page through the standard top and left-hand
banners and navigation in order to get to the main content.
Although as a keyboard user I have often found them useful
myself, but the magnification users were the ones who really
wanted them.

Deborah Kaplan
Accessibility Team Co-Lead
Dreamwidth Studios

On Mon, 17 Mar 2014, Hewitt,Susan (DSHS) wrote:

> I do not believe WCAG 2.0 AA includes skip links/bypass criterion as A does. But I don't think this is a good reason to abandon them. WebAIMs last motor disability user survey had roughly 60% saying skip links are somewhat to very useful (surprisingly they didn't find links that become visible on focus that useful.) Low vision users also found them useful. (http://webaim.org/projects/motordisabilitysurvey/)
>
> For this reason, and considering how easy it is to use them without a sacrifice of functionality or visual design, why we should stop using them? Until it becomes easier for non-mouse users to take advantage of ARIA (yes there are means for them to do so now but it's going to take education and outreach to make this known,) why deprive anyone of something that's potentially beneficial?
>
> Susan Hewitt
> EIR Accessibility Coordinator
> Texas Department of State Health Services
> = EMAIL ADDRESS REMOVED = | 512-776-2913
>
>
>
>

From: Jared Smith
Date: Mon, Mar 17 2014 9:22AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

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

From: Whitney Quesenbery
Date: Mon, Mar 17 2014 9:32AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

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

From: Cameron Cundiff
Date: Mon, Mar 17 2014 9:48AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

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

From: Jared Smith
Date: Mon, Mar 17 2014 10:08AM
Subject: Re: skip link breaks back button
← Previous message | Next message →

On Mon, Mar 17, 2014 at 9:48 AM, Cameron Cundiff wrote:
> Skip links have been fixed in Chrome's rendering engine:
>
> https://code.google.com/p/chromium/issues/detail?id=37721

This only fixes the in-page link issue for screen reader users. Screen
readers set keyboard focus to elements that are scrolled to (they
wouldn't need to do this if the browser itself set focus). This does
not resolve the issues for sighted keyboard users, thus the continued
need for the scripting 'hacks'.

Jared

From: Jim Allan
Date: Tue, Mar 18 2014 2:08PM
Subject: Re: skip link breaks back button
← Previous message | Next message →

complain to the browsers, file bugs


On Mon, Mar 17, 2014 at 11:08 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, Mar 17, 2014 at 9:48 AM, Cameron Cundiff wrote:
> > Skip links have been fixed in Chrome's rendering engine:
> >
> > https://code.google.com/p/chromium/issues/detail?id=37721
>
> This only fixes the in-page link issue for screen reader users. Screen
> readers set keyboard focus to elements that are scrolled to (they
> wouldn't need to do this if the browser itself set focus). This does
> not resolve the issues for sighted keyboard users, thus the continued
> need for the scripting 'hacks'.
>
> Jared
> > > >



--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Cliff Tyllick
Date: Tue, Mar 18 2014 3:11PM
Subject: Re: skip link breaks back button
← Previous message | No next message

You know what would be a great service to the community? A set of pages with the basics of:
* How to tell it's a bug (which, for the sake of this discussion, we'll say is "an issue to be brought to the attention of the responsible party").
* How to isolate the bug (browser? OS? AT? Javascript? HTML spec?).
* Where to report each type of bug—for example, is there a specific site to file TalkBack bugs? Or do I use the Android issue queue? And where is the Android issue queue—if that's what it's called.
* Tips for searching issue queues to be sure you have found a new, unreported bug.
If nothing else, a page that just points to each respective page where users can report a bug would be a big help. I have several project teams that would be using it now.

Cliff Tyllick
Corporate Accessibility Technology Office
AT&T



On Tuesday, March 18, 2014 3:09 PM, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:

complain to the browsers, file bugs


On Mon, Mar 17, 2014 at 11:08 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, Mar 17, 2014 at 9:48 AM, Cameron Cundiff wrote:
> > Skip links have been fixed in Chrome's rendering engine:
> >
> > https://code.google.com/p/chromium/issues/detail?id7721
>
> This only fixes the in-page link issue for screen reader users. Screen
> readers set keyboard focus to elements that are scrolled to (they
> wouldn't need to do this if the browser itself set focus). This does
> not resolve the issues for sighted keyboard users, thus the continued
> need for the scripting 'hacks'.
>
> Jared
> > > >



--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964