UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.
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.
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.
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.
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.
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 CodingForums.com, discussing the semantics of »
UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.
