June 11, 2008
Improving the Archive Navigator; Graceful Degradation
In this post, I will follow up on some of the comments and requests that generated around my newly popular post, How to Create Your Very Own “Archive Navigatorâ€. It might be handy to have that post open up in a second tab as I make a lot of references to it.
Graceful Degradation for Non-Javascript Users
When you build a solution with javascript, you should always try your best to make it accessible for non-javascript users. The non-javascript version doesn't need to be as fancy or even attempt to mimic what can be done with javascript, it just needs to be accessible. Case in point, turn javascript off and take a look at what happens to the archive navigator to the right. The tabs won't work, the box won't slide, but at least you can still access all the content inside the box.
Now if you took the code I wrote in last post and just pasted it, it's not degradable. If you were to view it without javascript, you'd see something like the following:
If you recall from the last post, there were three divs. One saying 'Hello World', another saying 'Hello Earth', and the last saying 'Hello Planet'. If a person browsing with javascript disabled saw this, the other two divs are hidden from them. And the reason for this is the CSS property we assigned to the parenting div: overflow: hidden;
When I thought about the easiest way to make my archive navigator accessible without javascript, altering the CSS was the simplest option as it required the least modifications. The most important modification of course is to remove that overflow:hidden; CSS property. What I did was replace it with: overflow:auto;. This allows the div to display scrollbars when given specific dimensions smaller than the inner contents. To restore the overflow:hidden; CSS property for javascript users, we can easily make that assignment using jQuery:
By doing the above, the archive navigator is accessible by those browsing with javascript disabled.
How To Make Tabs Like I Did
From the comments in last post, a lot of people wondered how I made the tabs in my archive navigator and how I got them to change style when clicked. First off, I did not use buttons, I used an unordered list:
Here is the HTML for my tabs:
If you're wondering about the <a href="javascript:;"></a> tags wrapping the text, it is meant to make the cursor change to make it look like it's clickable (the hand). I'm aware you can do this in CSS, but IE does not follow it. Also, instead of making href point to "#", I assign "javascript:;" instead so that the page will not scroll back to the top. It's a bit hacky, but it works.
Next, it's all jQuery. I created handlers for the three different li elements: #btn-popular, #btn-latest, and #btn-categories. Here's a sample of the handler I wrote for #btn-popular:
if(currentView != "popular") {
$("#btn-popular").toggleClass("selectedView");
Navigator.changeTabStyle();
}
Navigator.goToPopular();
currentView = "popular";
});
And now the breakdown of the code snippet above:
- For this handler, I want something to happen when #btn-popular is clicked. Hence the first line.
- Next I check if the user is already viewing the first div (which is the popular posts). I have a global variable called currentView which stores which div is currently being viewed. If it is not on the first div, the code inside this if statement is executed.
- In the if statement, I tell the #btn-popular li element to change its class to "selectedView". This class is defined in my stylesheet which gives it a white background and bolds the text. In other words, it makes it look like it's active. On the next line, I call a function called "changeTabStyle" which basically tells all other li elements (besides #btn-popular) to go back to their default class so that they no longer look active.
- In the next line of code, I call a function which moves the wide area to scroll to the first div (popular).
- Lastly, I assign the global variable to "popular" so that when another handler is executed, it can check what the user is currently viewing (as demonstrated in point 2).
Final Words
If you're going to take anything away from this post, it should be this: Develop for non-javascript users, then add javascript functionality later.
Why bother? It's true that it could just be a handful of people browsing without javascript, but think about the benefits; by making your sites, widgets or applications accessible, it becomes SEO friendly. With that said, people browsing with screen readers will not be missing anything either.
If you'd like a quick way to test your work with javascript disabled, I highly recommend the Web Developer Firefox Extension. There is a "Disable" menu which allows you to disable javascript in two clicks! Also, if you don't have Firebug already...get it.











Thank you so much! This is exactly what I was waiting for. You kick some seriously serious butt.
No problem.