If you just use a hash in the href of a back-to-top link, or a hash plus ID, are there any problems with that? Any browsers/other software in which it fails?
It works in the mainstream modern browsers that I’ve tried, plus IE6, but I can’t test any others. Just using a hash on its own seems too good to be true, like it’s relying on a bug. Should it go to an anchor, like in WebAIM’s article about skip links?
you’re on somedomain.com/foo.html
That’s equivalent to somedomain.com/foo.html#
Though if you’re using Javascript too, you might want to read this:
Get your hash the bulletproof way
she points out some interesting things about URL hashes.
Also, I suppose it’s true that a disadvantage of using a real token (#bar) means if whatever has the id of “bar” ever loses that id or gets it changed for some reason… a non-zero but non-existant url fragment identifyer will not move the page or refresh it when clicked!
I use this on purpose when I’m using anchors for stupid CSS tricks and I don’t want the users to get whisked away elsewhere, not even to the top of the page, if they were to click on it. Hence, my famous #void hashes. I have nothing with that id anywhere.
So anyway possibly # is safer. Though for some reason, like you, I feel I should link to a real token. Also, a lot of the time I don’t really want to bring people to the very top of the page. Usually I want to bring them back to the top of the main content. So, back to the main h1 usually. If you do a page refresh, you’ll get all the page info read out to you again: title, maybe page structure like number of links and headers, blah blah. If a user is brought back to just the main header or something, it should be clearer that there hasn’t been a page refresh or a page change… they are still on the same page, just a different place.
Sometimes I think “back to top” should be more specific: “back to the list” or “back to the start of main content” or something.
No, I don’t know of any browsers who don’t follow that behaviour for plain # marks (however, know that webkit browsers will only move the visual focus, NOT the keyboard focus!). They all should. Empty hrefs are another thing entirely, and of course lack of an href is famous for mixed results (IE doesn’t want to click on anything without an href).
Webkit sucks balls here if you’re not moused.
Ah, thank you Stomme poes.
Interesting point about the page refresh. I might link to the Content div, even though it has a top-margin (I think that it looks a little bit odd when the page doesn’t quite go to all the way to the top).
This came up because I was linking to my skip link div (the first in the mark-up after a fixed-pos logo), but then I added fixed pos to the skip links and forgot to test for what that might do to the top-of-page link. As you can imagine, it broke.
Re: Webkit browsers. At least they are not as weird as Opera, with its need for tabindex. I discovered that by accident while experimenting. Completely silly, because I bet that 99.9% of websites don’t bother having a default tabindex on every link.
At least they are not as weird as Opera, with its need for tabindex.
Unlike webkit users, tho, Opera users can navigate more freely with the keyboard. You can even skip by headers!
Actually, those to urls are not equivalent. Foo.html keeps the focus at the URL/address bar. Foo.html# puts the focus on the <body> tag. So foo.html# will allow users not to press tab a few times to drop into <body>.
Actually, I found that using a hash leaves the focus on the link (in Firefox, at least), so it does involve a few more key presses before focus is on the first focusable element again.
Do you have sample code for this?
Sure, but it’s nothing unusual:
<a tabindex="0" id="top" href="#">Top of page</a>
I’ve placed that as the last link in the footer and, when focussed and activated, Firefox goes back to the top of the page visually while keeping focus on that link (I can see my focus style still applied to it). Tabbing takes me through the browser’s interface and back into the page as if I hadn’t activated any links.
In a way, that’s probably not a bad thing because of how tabbing to an ID keeps the focus in the page and thus excludes the browser interface. One possible downside that I found is that this effectively demands that the back-to-top link is the last focusable item on the page, otherwise further tabbing will cause the page to jump down to the footer.
<!-- example.html -->
<a href="http://mycoolsite.com">sample</a><br />
<a href="#">Top</a>
If you went to /example.html, clicked top, your url will now will be example.html#. Clicking top again will keep the focus because it thinks it is there already. Try doing tabindex=‘-1’ vs 0
I wouldn’t take it out of the tab index.
You don’t need a tabindex on every link.
Yes, I know that. But it creates a tab order in Opera and a WCAG AAA test flagged a warning without it, so why not use it?
But anyway, that doesn’t change my point that it would be a bad idea to remove any link, unless it is off-screen, from the tab order by specifically setting a minus value, as you suggested.
…but -1 doesn’t remove it? Maybe check out Skip Navigation which links to [url=http://jimthatcher.com/news-070607.htm]In-page links, skip links, and IE Focus bug
Yes, it does, surely. I use it on a hidden form input that is positioned off-screen and, sure as I’m typing this, it takes this input out of the tab order. As I tab through the form, the off-screen input is skipped as if it didn’t exist. Turning off CSS confirms this. Adding it to a link produces exactly the same result: no focus.
I use -1 tabindex specifically for this reason… when I have something like this:
<h#><a href=“somewhere”>Some title, links somewhere</a></h#>
<p><a href=“somewhere” tabindex=“-1”><img src=“somethumb.png” w=“” h=“” alt=“”></a>
Brief text about the something…</p>
You don’t want a section with a bunch of links that all go to the same page just because that’s a pain in the butt for keyboarders… so while mouses may want to click on the image, keyboarders just want one (choose which place is best for your target group) clear link.
Otherwise you end up doing the whole HTML5 dance:
<a href=“somewhere”>
<h#>Some title, links somewhere</h#>
<p><img src=“somethumb.png” w=“” h=“” alt=“”>
Brief text about the something…</p>
</a>
Which drives me nuts, but I can see why people would want to do it.
I also use it when I have actual links as skip-link destinations: I need IE6 to get to them, and tabindex ensures that (bugs), yet nobody wants to stop there when tabbing through the page. It’s a destination, not a link.
Instead, though, you could use Javascript to simply change the -1 to 0 and manually move focus there… so I’ve been toying with the idea of, when using JS to create modal dialogues, bringing the page focus from the page underneath to the dialogue box using a destination with a negative tab index… it doesn’t have to be a link if you’re using HTML5, otherwise use a link.
Are you using the hidden attribute?
No. It’s hidden off-screen, as I said. It’s a honeypot, so setting the input type to hidden wouldn’t (I assume) work. And, as I mentioned, switching CSS off shows that it is taken out of the tab index.
Hm but can a bot still get access to it?
Have you gotten bots with it yet? If you have, damn, that would be nice. Right now I rely on people actually reading the label that says “don’t fill in!!”
Theoretical only at the moment, poes. But judging by what I have read, I see no reason at all why a bot would skip it, unless it’s smart enough to read my label (which is instructional, like yours). I expect it to be quite effective when the form is up and running.
Well, does a bot use tabindex is the question. If they do, they’ll also skip it like browser users, but if they don’t, then they’ll be able to focus on that input as well.