Maybe I have grown lazy, but I find myself often on one page of many, tapping the down key on my keyboard to scroll down and then hopelessly tapping the right key to go to the next page. Which does not happen.
I am quite surprised that functionality like this is not yet widely available at blogs and sites alike where page navigation and post navigation is always present.
At this point I have implemented some basic hotkey functionality here using the following javascript:
-
document.onkeyup = KeyCheck;
-
function KeyCheck(e) {
-
var KeyID = (window.event) ? event.keyCode : e.keyCode;
-
switch(KeyID) {
-
case 36:
-
window.location.href="/";
-
break;
-
case 37:
-
if (document.getElementById('prev').childNodes[0]) {
-
window.location.href = document.getElementById('prev').childNodes[0].getAttribute('href');
-
}
-
break;
-
case 39:
-
if (document.getElementById('next').childNodes[0]) {
-
window.location.href = document.getElementById('next').childNodes[0].getAttribute('href');
-
}
-
break;
-
}
-
}
The script listens for key presses. In this case something happens if a key with code 36 (Home key), 37 (Left Arrow key) or 39 (Right Arrow key) is pressed. I could give you a list of keycodes, but using alert(KeyID); after line 3 will give you a pop-up with the code of the key you pressed.
Time to make things happen when those keys are pressed. The Home key is going to take the visitor to my front page. Pointing the browser to "/", the root of my domain, will do just that.
Context sensitive hotkeys
Now the arrow keys are a different story. I want those to point the browser to the previous or next page when I am browsing pages, but also point to the previous and next post when viewing a single post. A predefined location will not do as there is no 'next page' url. They come in the shape of /page/2/ and /2006/attach-hotkeys-to-links/ and such.
The URLs I need are in my page, Wordpress put them there and they are always correct, well nearly always. To make sure I can find them with javascript, my previous link is always in an element with id 'prev' and my next link is always in an element with id 'next', like so:
-
<div class="page-nav">
-
<div id="prev">
-
<a href="/2006/set-the-margins-for-your-paragraphs/?phpMyAdmin=a1f29f4f36fb47fad3f2159e4a133b8d">previous post</a>
-
</div>
-
<div id="next">
-
<a href="/2006/attach-hotkeys-to-links/?phpMyAdmin=a1f29f4f36fb47fad3f2159e4a133b8d">next post</a>
-
</div>
-
</div>
Using the href value, context sensitive hotkeys are achieved with minimal effort. When there is no previous, or next link the div remains empty. Checking for a child node tells me if my hotkey has a location to point to or not, see line 9 and 14 in the script.
Going back or forth?
Once you have keys attached to your previous and next links you will probably face the endless 'which way is back' issue. I did. According to the browsers, left is back and right is forward (observe the back and forward buttons of your browser). Easy. The real question is; if I am browsing away from the current page to older blog posts, am I going forward or backward...? I am going to sit back and let you think that one through for yourself.
Compatibility Notes
I write very, very few javascripts and this particular one has not been tested in browsers other than Firefox and Internet Explorer. Check back here for changes as I drag the script through the various available browsers.
This article is mentioned at: Cagintranet Networks » Coming Attraction: Hot Key Accessibility
On October 13th, 2006 at 18:18
[...] OddEnd.com has a great article showing you how to easily implement hotkey functionality to your Wordpress blog or website. Using the Left Arrow, Right Arrow or Home buttons on your keyboard will allow you to navigate to the Previous Post, Next Post or Homepage (respectively). [...]
Jorge Epuñan says:
On October 13th, 2006 at 18:18
it works great on Safari 2. Congratulations, excelent resource, and tnx to share it.
Martin Kool says:
On October 13th, 2006 at 18:39
Thanks Jorge. Keep in mind when implementing this that the hotkeys always work, even when you are using a form input field or textarea.
Check the source of my site to see how I solved this for the search form using onfocus and onblur.
Paul Armstrong says:
On October 13th, 2006 at 21:14
Have you thought about this from a usability or accessibility standpoint? Doesn’t it seem that using the
accesskeyattribute would be a more defined way of navigating? Don’t get me wrong, this makes your site quite memorable, but it is like you are trying to change the standards that are already put in place—the ones that are tried and true.Also, on a Mac, the Home and End keys are used as page-scrolling keys. Granted, not many people probably know this or use it, but to the few that are might become seriously annoyed at losing the page they were on.
Lastly, I can’t even see the insertion point in the input and textarea fields in this comment form because it is black on (almost) black… quite confusing.
Martin Kool says:
On October 13th, 2006 at 22:18
Paul, I don’t think we have the same conception of ‘tried and true’,
accesskeyimplementation in the various browsers is anything but standard.I agree with you on the Home key. Although I believe you can use both the up and down arrow keys as well as home and end to scroll. Never the less, I broke an existing hotkey and that is not smart.
As for the black on black, there is a 10% difference in the brightness of form field’s border and background, but only 5% between the form field’s background and the page background. Thanks for pointing out that it’s hard to see, I may increase the contrast a bit.
Paul Armstrong says:
On October 13th, 2006 at 22:47
Have you really looked at how
accesskeys work? The implementation is standard, just different per operating system. See an example of accesskeys.And for the form stuff, I mean the insertion point… the spot at which the text you type will be placed in the body of the field. There should be a blinking line denoting the current position you will type in the text… it is there, but incredibly hard to see. Further testing shows that this is only a Safari problem. I’m not able to find any documentation on it, but it seems logical that this should be inherited from the element’s color style. So, I’m not sure what you could do at this point, seems as though WebKit could use some more work (and Apple should get the updates they’ve made working).
Martin Kool says:
On October 14th, 2006 at 2:12
The implementation is indeed standard, but the execution is not. While Firefox on PC follows a link when the accesskey is pressed, Internet Explorer (7) only focuses the link, requiring the Enter key pressed to have it followed.
If I was using hotkeys for extended functionality in forms, acceskeys would indeed be the way to go. With links however, behavior varies and any usage instructions would have to keep in account what browser the client is using.
It so happens that I am currently deploying this script for a site that needs to be accessible by disabled persons. The advantage it has is that of one keypress over a keypress combination. Pressing both the Alt key and another can be just as challenging as using a mouse.
Oh, I understand now what you mean with the insertion point, it’s worth checking out if it can be remedied even if it is a Safari-only problem.
Jader Rubini says:
On October 16th, 2006 at 14:53
Great job, man. Works perfectly on Opera 9.