There are not many aspects of web design that seem to ignite the same fascination in developers as making elements dynamic by hiding and showing them on user interaction. Collapsible lists, maps with hover elements and multi level drop-down navigations still seem to be hot and need to be part of a web site to make it "cool" and to "increase usability". Much like the magician conjuring the rabbit out of the top hat for the tenth time in a row, this design stunt does gets a bit stale though. Maybe it is time to take a step back and look at what we do.
Dynamic Page Elements-Cloak and Dagger Web Design - Troubles with Available Screen Estate (Page 4 of 10 )
One of the main reasons for using hidden elements is that you do not clutter your pages with text and navigation elements and that the user does not get confused by too many options at once. Unless we hide and show these elements via a reload, this does not apply to everybody. If we use Javascript or CSS to show and hide elements, we should make sure that the amount of content is not too overwhelming when all elements are visible.
This is especially important when we use multi level foldout menus, as these can become unusable when they exceed the available space.
Mouse Dependence
Hiding and showing page elements is a visual stunt (unless we do it on the backend and only write out the elements when they are visible), and thus we are tempted not to require a click to activate it but use a smoother way: The hover. This event takes place when the pointing device of the user is on the element but does not activate it. According to the CSS specifications [note 6] interactive user agents should support that, but may not be able to.
With the browsers currently available there is no reliable way to trigger a hover state with a keyboard. This means that a lot of well thought CSS-only solutions are dependent on a mouse or other pointing device. Even more annoying is the fact that the focus and active states, which by definition allow keyboard events and are the CSS equivalent of an onclick event are not supported properly by some browsers [note 7].
"Users without a mouse most probably have CSS turned off, too" is a nice idea to reassure ourself that we did well, but does not quite cut it.
One possible life saver is the accesskey attribute [note 8] and a lot of accessibility tutorials [note 9] swear by it - after all the accessibility recommendations [note 10] promote it and some accessibility certifications even require them.
Much like the recommendations for scripting [note 11], they appear great on paper (or on screen), but when we try to implement accesskey we run into some issues. First of all there is no indicator as to what the accesskey associated with the element is, as not all browsers or agents display them. This is a folly of the browsers and should not really be our problem, but if we use accesskey as the mean for keyboard users to use our solution, they should be made aware of that. Another issue is that there are not many keyboard shortcuts left at our disposal. The browser is already running inside several applications, all of them with their own set of keyboard shortcuts. By following the recommendations, we might overwrite some of their important functionality [note 12].
Any way we look at it, the only reliable solution to allow elements to be shown and hidden and remain independent of input device is by relying on the onclick event - as boring as that may seem. What scripting and the onclick event do allow us is to only apply the effect when it can be used: Rather than adding the script calls in the markup and guessing the script is available, we add the functionality via scripting.
Design Usability 
/ 14 
