Ah, I've got it. They are using an image replacement technique for the top navigation.
Thanks for this analisis Alastair.
Basically each text link is replaced with a background image, and the link text is hidden with CSS, which is not read out either.
Are they pulling in teh background images via CSS? Are they missing ALT values?
It's not Safari or Voiceover's fault, the text should be hidden with the method they have used.
Agreed, VO behavior is logically correct.
More in depth: The top navigation is in a list, each item contains a link, and each link contains a span with the text in it, e.g: <li><a href="/" id="home" title="Home"><span>Home</span></a></li>
Hmm. Would you judge the line above to be consistant with the WCAG 2.0 success criteria? I do not like it, but I cannot figure out how to fail it!
That span is given the CSS: "display: none;", so Safari doesn't display it, and Voiceover doesn't read it. JAWs generally does the same for items with display none, but must be falling back to the title in this case.
A reasonable assumption. JAWS is agressive in finding text to associate with a link.
The best practice technique for hiding text is not to set it not to display, but to move it off screen with something like: position: absolute; left: -999em;
I respectfully disagree about said technique being a "best practice" but it is a technique is that many people smarter than me champion. It feels like a hack to me, but maybe I just need to think about it more.
If they made that simple change, it would probably work fine.
Again, how are the background images pulled in?
