Clagnut’s global navigation is a JavaScript-driven drop down menu (the Site contents button graphical browsers will see top-right). An accessibility no-no, you might think, but I reckon otherwise. Here’s the mark-up (abbreviated for clarity):
<div id="nav">
<a href="#title" class="skip">skip nav</a>
<a href="/"><img src="/images/clagnut.png"
alt="Clagnut" /></a>
<h4><a href="#toc" onclick="return showhide('toc')">
Site contents</a></h4>
<ul id="toc">
<li><a href="/">Home</a></li>
<li><a href="/">Blog</a></li>
etc.
</ul>
</div>The drop down is marked up as a heading followed by a list, so browsers that don’t @import style sheets will see it as such and will be able to navigate happily.
If a browser does render the style sheets, but does not have DOM-capable JavaScript, the list and the skip nav link will be displayed as a horizontal navigation scheme below the logo (screenshot) using nav2.css.
If a browser renders the style sheets and also has DOM-capable JavaScript, I use JavaScript to import nav.css. This hides the list, requiring a ‘click’ on the Site contents button required to show it. Even though I’ve only used an onclick event handler (implying a pointing device) to operate the drop down, the mechanism also works with a keyboard on the browsers I’ve tested (IE6, Opera 7, Mozilla, Safari). Try it yourself by using a keyboard to navigate to the About page: load the page, press tab a few times (depending on your browser) to move the focus to the Site contents link and press return to display the drop down. Press tab three more times to move focus to the About link and press return to go to the page.
I’ve made an assumption that assistive technologies which render style sheets and run DOM-capable JavaScript work in the manner previously described (I’m particularly thinking of JAWS which runs on Internet Explorer).
So I think I’ve covered all bases from a technological point of view. I’ll also make the bold assumption that the implementation is adequately intuitive in all the scenarios described. I would therefore be confident in arguing for at least WAI-A compliance. Do you agree?
Sam Newman wrote:
Erm, under firebird 0.7 clicking Site contents button doesn’t actually do anything, but it works fine under IE 6.0
Tim wrote:
Firebird 0.7 on Redhat 9: SIte contents works fine using mouse or keyboard.
How about assigning an accesskey to the menu?
Rich wrote:
Firebird 0.61 on Windows works for me (keyboard and mouse).
Dunstan wrote:
Rich, that’s great. I remember asking you about that ages ago and you said “Naa, it’s accessible”, but I didn’t realise to what extent you’d figured it out.
Really good.
I’m just doing something at the moment that uses JS for layout and to apply styles where needed. It’s a handy way to provide two completely different looks depending on the browsers JS support.
Bravo.
Alan Skerrett wrote:
FireBird 0.7 – contents button works fine for me.
Dan wrote:
Same here: clicking site contents doesn’t do anyting for me with Firebird .7 on Windows 2K but works fine with IE 6.
Ryan Parman wrote:
Works brilliantly for me on Windows XP – every modern browser.
This is a brilliant piece of work! I’m impressed!
Rich wrote:
As I made a few changes today, I’m guessing the inconsistent results might be due to caching problems (particularly with /css/nav.css and /js/global.js)
Sam Newman wrote:
I really am confused as to why I’m not seeing the contents menu with firebird 0.7 (others seem to be). I’ll try my home machine and see if its something to do with this install…
Matt wrote:
Great idea. Thanks for sharing.
Andreas Bovens wrote:
Works like a breeze. One remark, though: the WAI require links to be seperated by more than just whitespace, if I am correct. So maybe it’s better to e.g. wrap something like <h1></h1> around the <img/> tag (?)
Rich wrote:
This is a Priority 3 requirement and is included because ‘older screen readers read lists of consecutive links as one link’.
In the case you quote, Andreas, a text link is followed by a linked image – this distinction should be sufficient for the two links to be dealt with separately.
David House wrote:
There are still some improvements that could be made to that code.
<img/> is a presentational tag most of the time, the preferred method of getting images in there is image replacement and CSS.
‘Clagnut’ isn’t a great alternative text. I’d envision something like ‘The Clagnut banner’ to be more effective.
Julian wrote:
David House wrote
“Clagnut? isn?t a great alternative text. I?d envision something like ?The Clagnut banner? to be more effective.”
I disagree. “Clagnut” is the perfect alt text. The text is a replacement for the image, not a description of either it or it’s location in/on the page.
David House wrote:
>I disagree. Clagnut is the perfect alt text. The text is a replacement for the image, not a description of either it or its location in/on the page.
Ideally, you’d describe the image so clearly that any blind user would be able to perfectly envision the image. Obviously, they wouldn’t want to sit through half an hour of pixel by pixel description, and the average person wouldn’t have the spacial awareness to put the pieces together anyway.
Rich wrote:
David, while I’m quite sure there are improvements that can be made to my code I can’t say I agree with either of your points.
It’s true that images are often used for presentation, however in this case I believe the Clagnut logo to be an intrinsic part of the content on the page, not just decoration. Therefore an
<img>tag is the correct treatment.If I was to replace the Clagnut logo with some ALTernative text, I wouldn’t write ‘The Clagnut banner’ in the top corner, I would write ‘Clagnut’. Therefore ‘Clagnut’ is the perfect
alttext – it doesn’t describe the image, it provides an alternative to the image.Julian wrote:
I think what David’s talking about is more suited to a longdesc but I still think he’s got the wrong appproach. Visually disabled people don’t need a perfoect decription of the image – they need to know what information is being conveyed by the site developer by using that image. The difference is subtle but important.
Just tested the contents menu a bit more in Firebird:
0.6 Win2K OK, 0.7 Linux OK
Matt wrote:
It may well be accessible to screen-readers, and even unstyled browsers, but I’m having a bit of trouble deciphering this…
I’m using Firebird 0.7 on WinXP SP1
Hope that’s of use.
Matt. :-)
Rich wrote:
Matt – you need to force a reload; there’s a caching problem going on.
Matt wrote:
Hmm, I tried ctrl-f5 a couple of times to no avail, but then I tried the old ‘go and make a ham and wild rocket sandwich for lunch’ manoeuvre, and that seems to have fixed it…
Ignore my crazed ramblings!
David House wrote:
Works fine with Firebird 0.6 (firewall problems with 0.7, I’m sure the menu looks the same), without Javascript works fantastically too.
Marco wrote:
Nice menu, it works with every new browser. Thank you :)
David House wrote:
Julian wrote:
“I think what Davids talking about is more suited to a longdesc but I still think hes got the wrong appproach. Visually disabled people dont need a perfoect decription of the image they need to know what information is being conveyed by the site developer by using that image. The difference is subtle but important.”
Maybe I’m going a bit overboard with this, but I disagree. Sometimes a short description can throw an entire picture out of context. For example, a comic strip would rely basically entirely on a longdesc description, because any attempt to cram it into alt would not be suffiecient.
I do agree now though, that ‘Clagnut’ will do as an alt description for the mostly transparent. I could analyse that image and I’m sure the typography etc. would provide useful information, but perhaps not applicable in this situation.
Phil Baines wrote:
Well, I think it’s well neat. Very good. One day all, or most, menus will be list boxes with styling! Well, maybe.
No, it is good.
Jonathan Chetwynd wrote:
Accessible drop down menu:
looks great but you wrote ” the mechanism also works with a keyboard on the browsers Ive tested (IE6, Opera 7, Mozilla, Safari).”
however there is a general problem using the keyboard to navigate on a mac.
please can you explain how yo use your dropdown menu in safari with a keyboard.
thanks
Phil Baines wrote:
hmmm, did I say “list boxes”? You know I ment jus Lists (<ul><li>’s) didn’t you?! Just wanted to clear that up.
Dam i’m dumb sometimes!
Rich wrote:
Ah yes. There is currently a bug in the released versions of Safari which means one cannot tab through links on a page. However, Dave Hyatt tells us that this has been fixed (see #6):
http://weblogs.mozillazine.org/hyatt/archives/2003_12.html#004377
So in truth I’m making an assumption about the full keyboard functionality in Safari.
Rich wrote:
Dave Shea posted a detailed analysis of this drop down on the Web Accessiblity Initiative Interest Group mailing list.
Sam Hampton-Smith wrote:
This may be of interest:
http://www.digital-halide.com/cssmenu
Sam