Skip to page content or Skip to Accesskey List.


Main Page Content

Dynamic Elements Cloak And Dagger Web Design

Rated 3.94 (Ratings: 4)

Want more?

Picture of codepo8

Chris Heilmann

Member info

User since: 29 Jul 2002

Articles written: 17

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.

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


was born.


is not a standard, it is a marketing word, and there was a time when a

new site needed to have a


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


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


to guess which ones they are

is flaky at best if not impossible.

Back to menu

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.

Back to menu

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 "


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 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


Back to menu

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.

Back to menu

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

"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


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


some of their important functionality

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.

Back to menu

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


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


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.

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


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.

Back to menu

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.

Back to menu

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.

Back to menu

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


only popups"

which turned out


to work on some browsers unless you create your CSS the right way

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.

Back to menu

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:

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.

Back to menu


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.

Back to menu


Currently employed in London as a Lead Front End Developer, Chris has been bouncing around the globe working for several agencies and companies. A web enthusiast from 1997 on workplaces include Munich, London, Santa Monica and San Francisco. More of Chris' writings can be found at and he blogs at

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.