There are not many aspects of web design that seem to ignitethe same fascination in developers as making elements dynamic by hiding and showing them on user interaction.
Collapsible lists, maps with hover elements and multilevel 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 10th timein 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.
Originally, HTML was not meant to have dynamic elements that show up whenthe user interacts with other elements. That is what links were for, and interaction with them meant a new page was loaded.
In the olden days we were amazed to see a bunch of links indifferent states (link, active, visited) and we looked awe struck at a blurb of colour or a rectangle slowly turning into an image.
These restrictions and the simplicity also had its merits:
Hiding and showing elements on user interaction originates from applicationdesign. Applications become more usable by not showing us all their options at once but allowing us to turn them off and on. Furthermore, we can arrange the elements freely on the screen and the application "remembers" their state and location when we end it.
Application design offers a much richer interface than web design toallow for these usability enhancements. An HTML page is a document, and resides inside several applications - the operating system, the browser and, if needed, an assistive technology like a screen reader. What makes it worse is that we don't know which applications are used, and trying to guess which ones they are  is flaky at best if not impossible.
A perfect dynamic elements solution should be unobtrusive and accessible:
These are the basic legalrequirements , but a out solution should also offer a bit more usability.
If possible, our solution should store the users' current status.Typically a hiding and showing solution initialises the page every time the browser loads the page. All elements that are to be hidden get hidden, which can be pretty annoying when you reloaded the page without wanting to. These unwanted reloads happen a lot when we use collapsible elements to simulate a whole web site in one document "to avoid long loading times".
As a web user who had to suffer badly designed pages for years we gotused to going back to the previous page when we ended up on a wrong one either via the "back" button or the equivalent keyboard shortcut - not via the navigation - thus initialising all hidden elements. This can only be prevented by storing the current state in a session, database or cookie.
Our solution should make sure that users get the information wherethey are in the page hierarchy at any point, the "you are here" effect of the boring old text links.
When talking to clients and designers about collapsible navigationswe will sooner or later stumble over the " three clicks rule". This rule states that users should find any content on your page with three clicks (otherwise they get bored and fed up and leave your site to spend millions on your competitors' sites).
This rule does not state that the three clicks should happen in thesame document and without a page load in between. Therefore we can satisfy it by adding a sitemap to our site, and voilà, two clicks and users can go anywhere on the page.
Of course this does not apply to a product catalogue, the three clickrule needs to apply to the sub section you are in there.
Multi level foldout menus replicating a sitemap do allow the user togo anywhere on the site from any page. For a sighted user with scripting and CSS turned on this can be very convenient (granted the navigation is easy to use and does not require neurosurgeon hand-eye coordination skills), but what is shown on our screen is not everybody's experience.
By adding the link data of the whole site to each page, we create a"content overload". Depending on the depth of our site, the user might see a nested list of 50 links, and will have to cope with this amount of data. Sighted users who can use a mouse might not have a problem with that, but keyboard and screen reader users will have to navigate through these links one at a time.
This can be a quite infuriating experience when you want to readlink 28 and link 29 afterwards - it means hitting tab 28 times, reading, waiting for the page to load and hitting tab 29 times, repeated ad nauseam.
Some browsers have"type ahead" functionality that jumps to a link when you type a word contained in it, and speech recognition systems can number the links for you. Regardless of these handy extensions, we still create a whole load of content that is not really relevant to this section of the site. A real world equivalent would be to print the register of a catalogue on each of its pages.
This is especially important when we use multi level foldout menus, as thesecan become unusable when they exceed the available space.
Hiding and showing page elements is a visual stunt (unless we do iton 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  interactive user agents should support that, but may not be able to.
With the browsers currently available there is no reliable way totrigger 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.
"Users without a mouse most probably haveCSS 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 theaccesskey attribute  and a lot of accessibility tutorials  swear by it - after all the accessibility recommendations promote it and some accessibility certifications even require them.
Much like therecommendations for scripting , 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 .
Any way we look at it, the only reliable solution to allow elements to beshown 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 does 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.
Let us take a look at the pros and cons and the feasibility ofdifferent solutions to turn page elements into dynamic ones. We will focus on what is the best practise for these, taking into consideration both accessibility and usability.
This type of navigation is the most common use of hidden elements, a navigationon the top or the left of the page which acts like the menus of applications or the windows start menu. The sub menus are positioned over the content and do not cause the rest of the content to shift when being expanded.
If we use this kind of navigation, we need to be aware of several problems:
If we use the whole sitemap as a navigation on each page, we do exactly whatwas explained earlier. Too many irrelevant links for this section will confuse users and the extra markup will slow down the page.
As the whole navigation collapses once users have chosen a page, there isno indicator as to where they are in the site, how many other elements there are in the same section and how many levels deep they are. We need to make them aware in another way (breadcrumbs, repeating the section navigation in a visible way).
The worst thing that can happen with a multi level drop-down menu is that itdoesn't fit the screen and either cuts off options or causes a scrollbar.
State 1 does not pose a problem, State 2 makes it impossible for asighted user to know what the options are and State 3 might make it impossible to use the menu. When the menu causes a scrollbar, and the menu hides and shows itself on hover rather than click, it gets hidden when the user tries to reach the scrollbar. This can become pretty frustrating.
To avoid these issues, we need to fix the page dimensions and checkif all menus fit the screen when expanded to the last level. As we cannot know the size of the users browser - which can be different to the screen resolution - this poses other usability and accessibility problems.
One annoying browser bug we have to be aware of is that some browsersshow flash movies and form elements on top of the menus instead of being covered by them. There is a work-around using an IFRAME , but that is hardly accessible. The safest bet is to ensure that the space all the expanded elements cover is free of multimedia elements, forms and - of course - frames.
A foldout menu has to be navigable via keyboard to remain accessible.Therefore it should expand and collapse when the user clicks it, for reasons explained earlier. This is less sexy and does not give the same experience as an application menu, but web development is just not application development.
Many foldout menus using hover to trigger the sub menus can even getmouse users into real trouble. Examples are menus that don't allow for a big enough space to hover over or show gaps in between menu and sub menu. It is pretty frustrating to navigate down into the third level just to see the menu vanish again when you slipped a bit.
When we use foldout navigations then we should make users aware that thereare more options to come when they activate this link. Studies have shown , that if users don't get that information, they won't use the navigation and get easily lost - rendering our whole effort to increase usability pointless.
Explorer tree menus are vertical list menus that expand and collapse thesub-menus when you click their parent element - much like the explorer tree on windows showing sub-folders and programs when you click on a folder name. While posing less problems than a foldout menu, there are still some pitfalls to avoid.
The rules of "content overload" apply here, the user may beconfused or even annoyed by the amount of links not related to this section.
A good explorer navigation should keep the current section expanded whenthe page loads - something that can be easily achieved. As the current sub section stays visible after choosing an element, highlighting this element and keeping a visited state should also be no big issue.
Expanding and collapsing the elements on hover is not possible withouttrading off keyboard users. Therefore we should stick to clicking the menu sections to expand sub-elements. As the menu items are arranged vertically, expanding the sub sections when hovering over each of the parent elements could appear rather annoying. Users want to reach link number 5, not expand and collapse all sub-menus in between 1 and 5 before reaching it.
Elements that have sub elements should tell the user so, to avoidfrustration loading a page when in reality there was a shortcut. We should make sure that this highlighting is only applied when the solution is working.
One not that common enhancement is to only show and hide certain partsof the page, for example a right hand extra navigation or extra information in a list of products.
Unless we add extra information this way, we don't have a case of contentoverload. The only remaining things to keep in mind are:
Once users chose to hide or show a certain page element, they should nothave to repeat their decision on each page. We should ensure the state is kept in a cookie or some other mean of data storage.
Unless we show and hide the element via including it or not on the backend,there will be a brief moment when the element is visible before it gets hidden. This is nothing serious, but users can be confused and annoyed.
We need to tell users that they can hide and show this part ofthe page, or that there is extra information.
One example of hidden and shown elements are "tooltips" thatappear when you hover over a navigation or an imagemap. Eric Meyer  lead the way for this functionality with his "CSS only popups"  which turned out not to work on some browsers unless you create your CSS the right way . They also have some other problems:
As these tooltips re-use already existing markup, there shouldn't be anycontent overload. We simply need to turn off CSS or scripting to see if the extra information is really helping or just represents a "nice to have".
For example, a navigation with spans inside each link which get positionedand shown outside the link via CSS can be a nice effect, but the same amount of text in each link might render the navigation hard to follow. HTML already has the title attribute for extra information that could be displayed as a tooltip .
Per definition, these effects are mouse over effects. However, as they arean enhancement and not a necessity, not much is lost if they don't work with alternative access.
One common mistake is to style the tool tips as if theywere clickable and yet hiding and showing them with a hover effect. Users will try to reach the tips with their mouse and get frustrated when they vanish.
Scripting is often used to enhance "internalnavigation" - a list of links pointing to anchors inside the same document. We can use scripting to hide content parts and show them when the user clicks the link, thus avoiding a long scrolling page. Effectively, we are simulating a site navigation in one document, which creates other problems:
As mentioned earlier, a wrong jump in a simulated paged navigationlike this might make the user try to go back via the back button or the appropriate keyboard shortcut. This will initialise - hide all elements, and show the first one - not the last one the user has chosen. There is not much we can do about that except for making the user aware that this is not a "site inside one document".
User won't be able to bookmark a certain section of the document, andsome browsers do not change the state of the links to visited once you jumped to this section. A good scripting solution should allow the user to directly jump in the page by supplying the anchor in the URL:
Furthermore, we could trace the clicks and set a cookie to showthe last section when the user visits the page again.
Unless we show and hide the element via including it or not on the backend,there will be a brief moment when the element is visible before it gets hidden. This is nothing serious, but can be annoying.
By hiding different content sections and showing them onclick we makeit easier to read the document on the screen. Some users, however, may want to print out or see the whole document. We should give them an option to do so.
Wrapping up, it can be said that it is very easy to use hidden elementsin a way that makes them more of a burden than a blessing. This applies especially to elements that are hidden and shown when the user hovers over other elements, which is a shame, because it makes the page appear a lot more interactive. Clicking elements is already known to navigate to other pages or sending off form data. When we change this behaviour to make our solution more reliable, we change patterns the users already follow without needing to think about what they do.
As we don't know the users' setup and their abilities we cannot create abullet-proof solution. Browser bugs add their share to render theoretically perfect solutions unusable. For the time being, we have to live with the certainty that we will repell possible users when we create dynamic page elements. It is up to us to judge if the benefits of them are worth that. Best case scenario would be to allow the user to turn off the solution via a page control.