Skip to page content or Skip to Accesskey List.

Work

Main Page Content

Navigation Our Visitors Travel Guide

Rated 4.05 (Ratings: 5)

Want more?

 
Picture of codepo8

Chris Heilmann

Member info

User since: 29 Jul 2002

Articles written: 17

Navigation and menus are not a technical matter. They are not confined to the world of IT but are used in real life, too. Navigation is a human interaction matter, human beings with all their issues and problems need and use it. Really successful navigations care about the visitors' needs, not promote a technique or our company's structure. What are we likely to find helpful in our local council office: An index of departments or a list of employees?

Real life navigations - keeping it simple

The success of a navigation device is largely dependent on how easy it is to use. At any time visitors should be able to find out:

  • Where they are
  • What other things can be found there
  • Where they can find help in case they get lost

Real life examples are the escalators and elevators in shopping centres.

  • At the entrance of the centre is a list of all the floors and what can be found on them.
  • Most of them will additionally show where the information booths, toilets and the accessible means of reaching the other floors (elevators, wheelchair ramps) are.
  • Really good shopping centres will have an extra sign pointing to a service index terminal or detailed maps of all the floors.

Up the escalator there is another sign, describing what can be found on this level and where the creature comforts are (information booths, telephones, toilets, changing rooms).

Sometimes this is a map, accompanied by a list of all the shops available on this level. On the other side of the escalator is the list of all the floors again with the current one highlighted.

This kind of navigation works and less successful centres were known to copy from the more successful ones. They make a lot of money, their visitor numbers are high and the shop owners are happy, as the navigation does send them visitors.

Web site navigations - why make it more complex?

The beauty of this approach is its simplicity; we don't overwhelm the visitors with options but give them what is needed at a certain point in time of their journey. Should they want more information, then there are the index terminals and detailed floor maps to help them find out more about "the big picture".

These real life examples can be translated into parts of a web site:

Real life exampleWeb site equivalent
List of all floors Main navigation
List of all floors with information what to find on each Homepage
Index TerminalsSearch functionality
Detailed map of all floors Sitemap
Detailed map and list of current floorSection navigation
Information about wheelchair ramps and lifts Accessibility Statement
Information booths Contact Facility / FAQ

The very nature of the web and indexing by search engines allows visitors to enter our site at any "floor", and with any technology.

That is why it is a tough call to go with a navigation that needs explanation, or depends on a certain technology. Even testing for the availability of this technology on the home or entry page does not mean visitors won't end up on pages that leave them stranded - they may come from a bookmark, link or search engine results list.

The flip side of the argument of "keeping it simple" is clients: A lot of them love cool navigation and consider their technical environment and experience the standard on the web.

We have some options in dealing with those:

  • Deliver, invoice, change our name, address and telephone number and hope they never contact us again.
  • Sign a maintenance contract and be the "doer" instead of the "expert advisor" for our client for the rest of the client relationship.
  • Take a stand and explain the diversity of the web and how it can work in their favour - after all, the speaker was invented for a hard-of-hearing person.

Our visitors and their experience

Spotting visitor diversity is a lot easier in a shopping centre. Well trained employees of shops, help desk staff and security can spot if a person needs

  • special aid; say a wheelchair,
  • to be allowed to take their guide dog with them
  • translation of labels
  • detailed information on products
  • guidance on choosing a product
  • a quick sit down, as they are out of breath

On the web, we know nothing whatsoever about our visitors.

Our visitors - the people we depend on to spend money, read our wisdom, or take part in our experiences - could be:

  • Visually impaired and need big fonts, strong contrasts and easy to find navigation
  • Blind and use a screen reader to tell them what is going on
  • Unable to properly use a mouse
  • Exclusively able or hardly able to use a keyboard
  • Dependent on switch access (a pedal operated by foot, a sensor operated by blinking of the eye, a headset with an extension to press keys)
  • Dependent on voice recognition
  • Deaf or hard of hearing
  • Cognitively impaired and confused by too many choices
  • Some more and any combination of the above

Enhancing by ability or by choice?

We can use technology to read some of the settings of the browser, but in effect this data does not help us much:

  • Screen resolution is not equivalent to available screen estate - visitors could use magnifying software or a large font size - and not by choice, but because they need to.
  • Plug-in availability does not mean that the visitor can benefit from the richer user interface this technology provides, a blind user with a screen reader might very well have Flash enabled (after all it is a great tool for streaming audio), but will have a hard time using a drag and drop Flash interface via a screen reader.
  • Scripting availability does not mean that the user agent really can render changes of the page. Our scripts might be able to hide things, but the visitor has no chance to reach them afterwards.
  • The language setting does not mean the visitors speak this language; they might be on a company machine or a public terminal.

We deal with human beings, not with their technology, therefore the idea of being able to predict what is going on by means of technology is doomed from the start.

We know the right thing to do - we would love to use an easy navigation and spend proper time on the layout, the backend functionality and making it pretty and easy to maintain.

However, we don't do it; instead we tend to spend a large chunk of design and development on the technical implementation of the navigation and run out of time and budget when it comes to cleaning up the code and write maintenance documentation.

The reasons are legion:

  • Clients have seen inaccessible navigation on their competitors' sites and like it
  • Clients don't care or just don't know the impact of an inaccessible navigation
  • Developers don't care or don't know about the impact of an inaccessible navigation
  • The inaccessible navigation gives the impression of easy maintenance (Only one JavaScript include!)
  • It is tempting to re-invent the wheel. As developers and designers one of our main drives is to make things better. A lot of times we miss that goal.
  • Some inaccessible navigation has a high benefit for "the average user" - whoever that may be.

This last reason is what should get us thinking. If the navigation is very usable and helpful to some, why not make it their choice to get it?

The quickest route is the best?

As an example, let's take multi level dropdown navigation, probably the most common seemingly helpful navigation around. Example: Screenshot of a multi level dropdown navigation&

This kind of navigation is very handy when

  • Visitors have scripting enabled - or a proper CSS browser, as you can do that kind of navigation without JavaScript by now
  • Visitors have a mouse, or the navigation is properly keyboard enabled
  • Visitors have enough screen estate at their disposal - as scrolling the screen might collapse the menu.
  • Visitors have good hand / eye coordination and can read very small type.

A lot of assumptions we have to make. Technology cannot help us with most of these problems. Simply resizing the font shows one of the problems we might oversee when developing this navigation.Example: Screenshot of an overlapping multi level dropdown navigation

Keyboard users will have to tab through all of these links every time they loaded one of the pages, voice recognition users might not be able to expand them, in short - we will have trouble making this navigation accessible. There is a way though.

Leaving the choice to the visitor

As there is simply no way to predict the ability of the visitors, the easiest option is to leave the choice to them. The site gets an easy, logical navigation that only shows the options necessary and offers a checkbox, or a button marked "enhanced navigation" with a "what is this" link explaining what it is a about.

Once chosen, this choice can be stored in a cookie or the visitor's profile and there is no need to choose again.

If the functionality we need is based on a technology like Flash or scripting, the button can be generated via this functionality, thus never bothering those who don't have the choice to start with.

Basic accessibility navigation guidelines

Following are some guidelines that help determine if our navigation has a chance to be accessible or not. Any time we have to say no there is a problem.

  • If scripting and styles are disabled

    • is the navigation still clearly visible and understandable?
    • is the current section obvious?
    • is the amount of links available easy to handle via keyboard and are they needed in the current context?

  • If scripting and styles are enabled

    • is the navigation still usable via a keyboard?
    • does the visitor have to tab through lots of invisible links?
    • can the navigation be resized in the browser without overlapping?
    • is the navigation dependent on a certain screen estate?

  • Any of the above with the other two combinations (Scripting on / CSS off, Scripting off / CSS on)
  • Is there enough contrast between the background and the foreground of the navigation?
  • Do all the links make sense out of context (some assistive technology does offer the page links and the headings as lists to ease navigation)
  • Do all links with the same wording point to the same page?
  • Are the link names easy to understand?

Navigation is a tool

Navigation is one of the most important parts of the site; however, the most important part of a page is the content. If our navigation grabs the visitors' attention and distracts from the content, then it failed its purpose. The content should determine the navigation, not the other way around.

This is easy to forget, as navigation is one of the few things us web developers and designers can play with. At the start of the project we have a rough idea of the sitemap, whereas the content is not always ready or even planned out. It is up to us to tell the client that the content is what people will look for and come for, not how cool or usable the navigation is. The best navigations on the web are the ones we cannot remember, but pointed us quickly to the right place.

If there is a lot of time and budget to be spent, then it should go into proper search functionality and defensive measures - the error pages, warning messages and information pages, not a singing and dancing navigation.

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 http://icant.co.uk and he blogs at http://wait-till-i.com

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.org Evolt.org 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.