Developer's manual

The semantics of menu indicators

Bear with me ...

If you use submenu indicator-arrows then at some point it's worth thinking about the meaning of the indicator you use - if you use a textual-indicator, the question is what text to use; if you use an image, it's what to put for the alt text.

Look around the web and you'll see a lot of sites using characters like "»" and ">" within menus, crumbtrails or other navigation. But this is a semantically dubious practise - those symbols have another meaning - the former is a French quotation mark; the latter is a greater-than symbol.

And that matters ... why?

This is potentially confusing for some people, particulary for someone who's using a screenreader or on-screen narrator - JAWS, for example, will say right double angle bracket and greater, respectively, which doesn't help at all - it certainly doesn't convey the same meaning.

So, what's the answer?

Well ideally, what you want is one or more characters to convey the same meaning irrespective of modality.

Having said that, I don't know if there is a definitive answer - the best I can think of is to use two or three dots: "..", "...", or an ellipsis character. I think that should be fairly-commonly understood to mean "and there's more" when heard as speech, but at the same time, it's small and similarly-meaningful enough to do the same job for graphical browsers - either as a textual indicator, or as the alt-text of an image.

Another possibility is to use an image-arrow for graphical browsers and put a descriptive label for its alt-text - something like "menu" or "submenu" - which when read-out in a screenreader tells the user they're moving to another branch.

But that's not the half of it ..

Some screenreaders (such as JAWS) give heirarchical information when reading through a complex list - it tells you how deeply nested the current list is, and how many items it contains. But it only does this in SayAll mode - if you tab-navigate between links they're read out linearly, with no sense of structure at all. When tab-navigating, JAWS reads the alt-text of image indicators, but it doesn't read them when in SayAll mode - actually that's okay, because the alt-text information isn't really needed if heirarchical information is given instead.

Home Page Reader is like tab-navigating in JAWS - HPR reads the indicator alt-text but otherwise gives no heirarchical information. At any rate it usually reads the alt-text, but sometimes it just doesn't, for no good reason I can find.

However the alt-text still isn't really enough - although it can convey moving from one level to the next, there is nothing to convey moving back up the heirarchy from a nested level to its parent. Without that information, knowing that you're going to a nested list might not be especially helpful after all.

Navbar headings should help

You should be able to improve usability for screenreaders and other serial-browsers, by putting headings inside the navbar list - for example an <h3> around each top-level link. This will allow serial browsers to jump from branch to branch, using their "headings reading mode" or equivalent, and provide additional semantics that should help to distinguish a navbar link from a menu link.


I don't know; perhaps there are no easy answers. In most of the demos on this site I've gone for menus with an <h3> heading around each navbar link, and image-indicators with ".." as the alt-text.

That seems like a rounded compromise to me, but what you do is your call. If you have an epiphany about this, please do let me know.

You might also be interested in a thread at, discussing the semantics of &raquo;


We would like your feedback! Take the UDM4 Survey!

UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.