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 10th 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.
* History of dynamic page elements
* The perfect dynamic elements solution
* Current problems
o Three clicks vs. content overload
o Available screen estate
o Mouse dependence
* Current solutions
o Foldout or Dropdown navigations
o Dynamic list navigations
o Dynamic page elements
o Tooltips
o Enhanced internal navigation
* Conclusion
* Links
The history of dynamic elements
Originally, HTML was not meant to have dynamic elements that show up when the 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 in different 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:
* Sites were designed to tell us at any stage of our journey where we are and where other pages with related content are - a static navigation on one spot.
* The different link states made us realise where we have been already and what is new without any search effort.
* Deep sites never dared to show us links not related to this sub section in the main navigation - the sitemap, the search and internal promotions fulfiled that job nicely.
When CSS got supported and Javascript allowed us to modify elements and their CSS attributes "DHTML" was born.
"DHTML" is not a standard, it is a marketing word, and there was a time when a new site needed to have a "DHTML" intro and elements, or else it would not show up in the "cool pages" lists of our web world. Browser shortcomings and newly emerging browsers triggering the need to change the scripts over and over again soon made it transparent though that "DHTML" was just not reliable enough. These incompatibilities and the high maintenance made many an obtrusive and badly designed web site go the way of the Dodo bird. We are now at a stage where we can create some of these effects in CSS only, and our Javascript skills have become more sophisticated[1]. We can test if a browser supports a certain technique before we apply it, and we have browsers that are more sophisticated and standards-literate at our disposal.
The origin of dynamic elements
Hiding and showing elements on user interaction originates from application design. 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 to allow 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 [2] is flaky at best if not impossible.
The perfect dynamic elements solution
A perfect dynamic elements solution should be unobtrusive and accessible:
* It should only apply itself when it can be applied to avoid hiding elements that cannot be shown again.
* It should be independent of input device
* It should enhance existing markup rather than creating crucial content via CSS or Javascript.
These are the basic legal requirements [3], but a out solution should also offer a bit more usability.
Maintaining the current state
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 got used 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.
Telling the users where they are
Our solution should make sure that users get the information where they are in the page hierarchy at any point, the "you are here" effect of the boring old text links.
Current problems of collapsible elements
"Three clicks" vs. "content overload"
When talking to clients and designers about collapsible navigations we will sooner or later stumble over the " three clicks rule"[4]. 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 the same 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 click rule needs to apply to the sub section you are in there.
Multi level foldout menus replicating a sitemap do allow the user to go 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 read link 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"[5] 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.
Troubles with available screen estate
One of the main reasons for using hidden elements is that you do not clatter 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 [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[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 [8] and a lot of accessibility tutorials [9] swear by it - after all the accessibility recommendations [10] promote it and some accessibility certifications even require them.
Much like the recommendations for scripting [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 [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 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.
Hiding and showing solutions currently in use
Let us take a look at the pros and cons and the feasibility of different 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.
Foldout or Dropdown navigations
This type of navigation is the most common use of hidden elements, a navigation on 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:
1. Content overload
If we use the whole sitemap as a navigation on each page, we do exactly what was explained earlier. Too many irrelevant links for this section will confuse users and the extra markup will slow down the page.
2. No "you are here" state
As the whole navigation collapses once users have chosen a page, there is no 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).
3. Screen estate restrictions
The worst thing that can happen with a multi level drop-down menu is that it doesn't fit the screen and either cuts off options or causes a scrollbar.
Illustration of three different states of a multi level dropdown navigation
State 1 does not pose a problem, State 2 makes it impossible for a sighted 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 check if 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 browsers show flash movies and form elements on top of the menus instead of being covered by them. There is a work-around using an IFRAME [13], 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.
4. Mouse dependence
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 get mouse 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.
5. Unknown functionality
When we use foldout navigations then we should make users aware that there are more options to come when they activate this link. Studies have shown [14], 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 Menus (collapsible list navigations)
Explorer tree menus are vertical list menus that expand and collapse the sub-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.
1. Content overload
The rules of "content overload" apply here, the user may be confused or even annoyed by the amount of links not related to this section.
2. Not maintaining the current state
A good explorer navigation should keep the current section expanded when the 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.
3. Mouse dependence
Expanding and collapsing the elements on hover is not possible without trading 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.
4. Unknown functionality
Elements that have sub elements should tell the user so, to avoid frustration 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.
Collapsible page elements
One not that common enhancement is to only show and hide certain parts of 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 content overload. The only remaining things to keep in mind are:
1. Not maintaining the current state
Once users chose to hide or show a certain page element, they should not have to repeat their decision on each page. We should ensure the state is kept in a cookie or some other mean of data storage.
2. Jumpy display
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.
3. Unknown functionality
We need to tell users that they can hide and show this part of the page, or that there is extra information.
Tooltips and hidden extra information
One example of hidden and shown elements are "tooltips" that appear when you hover over a navigation or an imagemap. Eric Meyer [15] lead the way for this functionality with his "CSS only popups" [16] which turned out not to work on some browsers unless you create your CSS the right way [17]. They also have some other problems:
1. Content overload
As these tooltips re-use already existing markup, there shouldn't be any content 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 positioned and 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 [18].
2. Mouse independence
Per definition, these effects are mouse over effects. However, as they are an enhancement and not a necessity, not much is lost if they don't work with alternative access.
3.Giving false hope
One common mistake is to style the tool tips as if they were 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.
Enhanced internal navigation
Scripting is often used to enhance "internal navigation" - 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:
1. Changing user behaviour patterns
As mentioned earlier, a wrong jump in a simulated paged navigation like 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".
2. Disallowing bookmarking and direct linking
User won't be able to bookmark a certain section of the document, and some 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:
http://www.foo.org/index.html#bar
Furthermore, we could trace the clicks and set a cookie to show the last section when the user visits the page again.
3. Jumpy display
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.
4. Cutting off content
By hiding different content sections and showing them onclick we make it 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.
Conclusion
Wrapping up, it can be said that it is very easy to use hidden elements in 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 a bullet-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.
* [1] Unobtrusive Javascript self training course: http://www.onlinetools.org/articles/unobtrusivejavascript/
* [2] Browser detection via Javascript: http://www.quirksmode.org/js/detect.html
* [3] Legal accessibility requirements: http://www.section508.gov/index.cfm?FuseAction=Content&ID=12
* [4] Debunking the "3 clicks" myth: http://www.uie.com/articles/three_click_rule/
* [5] "Type ahead" functionality in Mozilla http://www.mozilla.org/projects/ ui/accessibility/typeaheadfind.html
* [6] Pseudo class CSS specifications: http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes
* [7] Hover and Active problems http://www.quirksmode.org/css/hover.html
* [8] Accesskey HTML specifications: http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey
* [9] Accesskey tutorial: http://www.alistapart.com/articles/accesskeys/
* [10] Web accessibility guidelines on accesskey: http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-accesskey
* [11] Accessible scripts guidelines: http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts
* [12] Problems with access keys: http://www.wats.ca/articles/accesskeys/19
* [13] Form elements covering menus in IE hack: http://homepage.mac.com/igstudio/design/ulsmenus/vertical-uls-iframe.html
* [14] Usability study on dropdown navigations: http://www.uie.com/articles/users_decide_first/
* [15] Eric Meyer, CSS expert: http://www.meyerweb.com
* [16] Pure CSS popups: http://www.meyerweb.com/eric/css/edge/popups/demo.html
* [17] Problems with pure CSS popupshttp://www.quirksmode.org/css/ie6_purecsspopups.html
* [18] Nice titles: http://www.kryogenix.org/code/browser/nicetitle/
