Hiding content, accessibility, and the onload problem
Posted by Jason on September 15th, 2008Since I joined the Mixx team (a year and some change ago) and began cranking out the HTML, CSS, and JavaScript that you see and use every day, I made it a point to build features out with accessibility in mind. Mixx has a great variety of users comprising all races, colors, creeds, and capabilities. It was (and remains to this day) important to us that we provide a great experience for our users while not leaving anyone out in the cold.
As most of you know, there’s a ton of interactivity on Mixx—voting, reporting, submitting, interacting with YourMixx—the list goes on. Each of these elements involves a different interaction with the application and every one of them involves manipulating content on-screen using a combination of JavaScript and CSS.
In an effort to accommodate users (or, more directly, their browser of choice) who have JavaScript turned off, we take the approach of displaying all content by default and then using JavaScript to hide the appropriate elements. The easiest to observe example of this is on the permalink pages. With recent redux of the permalinks, we added some new “tabs” (for lack of a better descriptor) below the entry information and above the comments: Activity, About this site, and Related.
When browsing to a permalink page, depending on how zippy your Internet connection is, you may notice that the three tabs are expaned and stacked on top of one another initially. After a brief pause, they’ll snap away and they may then be accessed by clicking on their respective button. This is, at the most basic, the situation described above. Page content loads. JavaScript does its job and hides the appropriate pieces.
In a perfect world, this would happen instantaneously and no one would notice. In the real world, Internet connections are variable, web servers hiccup, and external resources (like Google Analytics) have the side-effect of stalling firing of local scripts. The last point there is the one of concern to our discussion. Steve Souders, in his excellent book High Performance Web Sites, goes into great detail about why this stalling happens. Check out Chapter 6 on “Problems with Scripts.”
So what do we do? Let’s first take a look at how Mixx currently works.
As we’ve observed, our HTML and CSS style everything on the page and display elements by default. Once everything is loaded up, the Mixx JavaScript (using jQuery, a subject for another post) uses $().ready() to fire off our onload events. The appropriate bits hide away and we’re done. This is great as far as “best practices” and all that are concerned, but less-than-great from a perceptual viewpoint.
Robert Nyman, in his post How to hide and show initial content, depending on whether JavaScript support is available, outlines a technique where you add a <script> element to the <head> of your document which calls an anonymous function which, in turn, adds a CSS file to your page. The CSS file contains a single line with a selector (in his case an ID-based selector) that tells an element to not display.
It’s a brilliant solution that overcomes the onload problem introduced by remote assets. The only amendment I would make to his example is to use a class-based rather than ID-based selector. This way, you can set up a single class (”.alt”, for instance) and apply it to all elements you wish to hide.
Simple as that, really. Robert offers us an extensible solution to a problem that’s been troubling developers more and more. So why, then, you ask, has Mixx not implemented this? “Time”, mostly. We’re a small team here with a huge list of things to do! I promise you, though, that this will be implemented as we have time.
Have you found other effective solutions to this issue? If so, leave us a note in the comments!
3 responses to "Hiding content, accessibility, and the onload problem"