1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

The four lessons include a view of the big picture, coding, usability and design challenges, and understanding the relationship with other W3C standards and activities. Your instructors are among the best: Stéphane Boyera is leading the W3C’s work on the mobile web in developing countries, Dominique Hazaël-Massieux is the Mobile Web Initiative’s Activity Lead, and Philipp Hoschka is the W3C’s Deputy Director and leading the Ubiquitous Web activities. For more information check the Mobile Best Practices recommendation.

In this article:

• Case study
• Best practices in HTML
• Best practices in CSS
• Best practices for search engines

Case study

Over the years we made several technical analyses for the clients’ own websites and some of their competitors, including major German broadcasting companies, TV program journals, and a couple of large online travel sites.

We were checking for overall performance like file sizes as well as best practices in (X)HTML, CSS, semantics, and some other aspects of friendliness to users and search engines. We mostly skipped accessibility because there were already severe errors in the other areas.

It’s not like these websites were made by some backstreet crack houses agencies. All have a well-known logo stuck to them, most of them get more than a million visits each month, some up to more than a hundred million. Still the reviews felt like a time-travel to 1998. In our elite circles we speak about a “new professionalism,” but HTML in the wild is still a very dark and ugly jungle.

Most common errors were missing alt-attributes and unencoded &-characters in URLs. Also quite common were XML endslashes in HTML documents, or hacks from the nineties: proprietary attributes like background in table data, height in a table row, marginwidth, marginheight, topmargin and leftmargin, or missing type attributes in style and script tags.

Getting into the depths of old-school programming we found proprietary tags like <nobr>, <ilayer>, or <spacer>, misconceptions like valign="center" instead of "middle", forgotten closing tags, or tag soup like the classic form between table rows (to prevent top margins), block level elements inside of inline elements, <p> tags around everything (including tables and headlines!), or script tags before or after <html> </html>. Especially ad servers and site statistics were infamous for their crappy stone-age code.

Only a few were missing a doctype declaration (DTD) altogether, most ran HTML transitional 4.01 in quirks mode, only one claimed to be XHTML 1.1 (gasp). Seven out of ten had a charset encoding, but only the XHTML website did care to define the site’s language. Almost all had no clue about CSS positioning and used table layout.

Sometimes we encountered code where developers obviously hadn’t understood even the most basic principles of CSS 1. They used either font tags with style attributes, or other tags just like font tags with a lot of repeated inline style. Thus the advantages of CSS through central style sheets with classes and IDs were counteracted.

It didn’t come as a surprise that the few websites using CSS 2 for layout had significant smaller file sizes. Those with CSS 2 had between 15-21 KB of HTML, their competitors with table layout 55-95 KB. Still you got to pay attention to the file size of images and rich media (including banners) as they frequently blow up the total amount. Be aware of DHTML menus, as they have a tendency to get out of control sizewise (40k JavaScript in one case, 85k in another). Less than a total of 100k for the home page should be sufficient, even for sites with rich graphic interfaces.

I don’t want to bore you with further rants about burning bandwidth with 600k large home pages (multiply that by a million), hence we thought positive and made a checklist of best practices. Although the checkpoints appear to be quite obvious and common sense when you read them, you might be surprised that the best website managed to fulfil 22 out of 29 checkpoints, the worst only 8, with an average of 12.

By the way, the HTML and CSS part of the checklist is more or less the same we use for testing the qualifications of job applicants. We associated a severity grade (major, average, minor) with each checkpoint, and for each error in the small task we give them we subtract 3, 2, or 1 point(s) respectively from a maximum of 100. Half the amount is subtracted when a checkpoint is partially fulfilled. We adopted that system from the German accessibility test — it’s fair and a great way to compare test results.

Here’s the short version of our checklist. Feel free to make your own severity rating. Just be consistent in your own tests to get comparable results.

Best practices in HTML

1. The document must validate as HTML or XHTML.
2. The document must have a DTD.
3. The document must have a character encoding, either through a HTTP header or a meta tag.

4. The document should have the language defined in the following ways:

   • <html lang="en">
   • <html xml:lang="en">
   • <meta name="content-language" content="en">
5. All attribute values should be quoted. In XHTML, quotes are mandatory.
6. Element and attribute names should use a consistent case to enhance readability, preferred is lowercase for XHTML compability.
7. Code should be well <!-- commented --> to help maintaining developers to get a fast grip of the basic structure and key concepts.
8. Code should be consistently indented, tabs preferred over spaces.
9. Images, image maps and scripted content must have an alt-attribute with an appropriate value.
10. Images should always specify their width and height to allow browsers to continue rendering while waiting for the image data.
11. Some special characters like ", <, >, and & (especially within attributes like href or src) must always be replaced by their character entities or numeric character references (NCR). Also characters not included in the character set, like € in ISO 8859-1, must be replaced. The W3C I18N activity group further recommends to replace other special characters like –, but not common characters like “ü” in German texts or “é” in French to maintain code readability.
12. script and style tags must have a type attribute.

13. JavaScript code should be included using external files for caching and better maintenance.

    Of course with Yahoo’s performance research about browser cache and HTTP requests you could discuss if external files load faster with several server requests through script src="foo.js" or just one request and internal HTML code, but either way you should use central, non-redundant files and include them in one way or another.

Best practices in CSS

1. CSS must validate.
2. Elements should be positioned with CSS 2, not tables.
3. All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS 2.
4. Text should be formatted with CSS 1, not with font tags.
5. All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.
6. External CSS files should be sent with the correct MIME type (text/css).
7. CSS classes and IDs must be valid, i.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.

Best practices for search engines

1. Use a descriptive title with the name of the website and consistent separating characters in it.
2. Use keywords, keyphrases, and a description reflecting the page’s content.
3. The URL should be descriptive, human-readable, easy to remember, to bookmark, and easy to spell on a phone. Don’t bother the user with file extensions, thus you will be future compatible and independent from your current software.
4. Use the Robots Exclusion Standard, i.e. robots.txt.
5. The content should be as high up in the code as possible as it gets more relevance there.
6. Use proper semantic code, like headlines, or list items for anything that resembles a list. Don’t use list items to get bullet points or headlines to set bold text.
7. Use <link> tags to specify relations between pages, like rel="start", chapter, prev, or next, as search engines might value your start page more, or browsers could preload next pages.
8. Use a favorite icon for bookmarking and to keep your error log clean.
9. Use the PICS standard to signal search engines and filter programs that your website is safe for kids.