Any site which deals with the UK in regards to selling or offering goods and or services can be legally held accountable for failures in meeting accessibility guidelines as they relate to the trade being undertaken.
And what about the US?
Currently I don’t think any Dutch businesses are worried about accessibility by foreigners either. WCAG2 rewrite is coming this summer, but it’s only known of by web people.
Agreed. :hover works just fine in FF2 & 3, O since way back, and IE 7 & 8.
In fact, the only major browser that pure CSS drop downs don’t work for is IE6 and you can target an alternate stylesheet or script for that using conditional comments.
On my website I have several fallback stages. Modern browsers get a fully functional :hover driven menu as the first option since this is what works best. They can handle it, so I’ve enhanced their experience to that level of functionality.
For IE6 users, I’ve included a conditional comment at the end of the page which inserts a script for IE6 and below. It runs a JS-based drop-down function that drives the menus. Not ideal, but it provides identical functionality for all IE6 users with JS on.
For IE6 users with JS off (with CSS on), the additional links on the menus do not appear, therefore, I’ve created other nav areas (at the bottom of the page) where all the same links appear. This is not as convenient as the menus, but the primary links are still available on the nav bar, and the secondary menu links are available at another location on the page.
And last but not least, for IE6 users with JS and CSS off, the CSS - which generates the menus and hides them - is never applied in the first place. They get the same experience as someone using a text-browser or related type of equipment. The navigation appears as an unordered list with nested lists that provide secondary links.
Ok, so maybe I’m missing something here, but this is from “The Right Way to Make a Dropdown Menu”, which can be found here: http://www.sitepoint.com/blogs/2009/04/01/the-right-way-to-make-a-dropdown-menu/
Pure CSS menus are an interesting proof of concept, but that’s all they are. Eric Meyer’s invention of them led the way to our re-thinking how menus should be built in the first place, but in of themselves they are not suitable for real-world production use.
I have a couple of sites with a fair bit of content and am often thinking about the best way to organize the site navigation. It seems to me rather impossible to make all of the content which would be accessible from a dropdown menu, also accessible without it (when JavaScript is turned off).
Thoughts?
P.S. Should probably mention I settled for accordion style navigation, where the whole thing unfolds as soon as JavaScript is turned off, and al the links are accessible.
ABSOFRAGGINGLUTELY. That half-assed crap should have gone the way of the dodo the moment we could start using :hover on any element.
Mind you, legacy you do need scripting to make it work in IE6 - but even if the dropdowns on a menu do not appear, the parent element should at LEAST have a working link on it so that people can still depth-navigate the site.
Too many people are abusing javascript just to serve static content and in the process schtupping the people who don’t want that crap (half a million downloads of the FF noscript plugin can’t be wrong), schtupping yourself on making it harder to maintain, and possibly even fudge packing yourself when it comes to bandwidth… See the endless bloated scripted garbage websites that blow half a megabyte on delivering 3k or less actual plaintext content.
Accessibility is NOT just about availability - it’s about choice… and a lot of people will choose NOT to let any of that bloated goof-assed garbage on their machines… and as more and more people go mobile, the “gee ain’t it neat” trash like javascripted menus or worse, flash navigation might not be available to them.
As I’ve said in several posts today, the “ENTIRE POINT of HTML” is to markup the content in a device and capabilities independent fashion.
Which means if you have links or content that are NOT in your markup, or are linked in via techniques like framesets, iframes, DHTML or using AJAX to replicated frames functionality, you’re missing the point of HTML and do NOT have accessibility.
Talking of accessibility: is a menu which only functions if JavaScript is enabled count as inaccessible, or is this more a choice of the user (i.e. more of an availability issue)?
My boss made the mistake of buying a brand new mobile phone that, unknown to him, did not support Javascript (though even if it did, it would mean his battery life would be severely shortened by bloated scripts running on the thing).
His second mistake was using some analytics software which was so badly written, it requires Javascript for users to log in (never mind the server should be the ONLY one logging people in and out).
I wouldn’t call that a choice, I’d call that inaccessibility for three reasons… but, YMMV. It seems wrong when something is called a choice but is something people can’t help. If I can choose to turn Javascript off, then I can choose to turn it back on. But I can’t choose my skin colour or how abled my body is, and in a limited sense the same can go for software (depending on price, availability, practicality). So it seems more like a punishment. And for something like a menu, which has no need for Javascript (even if it’s a dynamically created menu, that’s server’s job) for basic functionality, it’s just plain discrimination. So the next question is, is the discrimination necessary to get something somehow to work for some people?
My web-based mail just yesterday apparently decided that (some major upgrade they did last night). I can no longer check my mail via Lynx, which is kind of a shame because I was used to that. But, I can still do it in a graphical browser, so it’s not inaccessible to me.
In a perverse way; it is actually ageing what we should focus our efforts more on as it’s the only common practical denominator for all humankind regarding website accessibility. Unless of course you stop-ageing in which case a website will be of little personal use anyway. 
Wow, that article is trash - Though that could just be a kneejerk reaction to the first bullet point For example I mouseover a element I want it to open NOW, not after some goofy delay - the same reason I turn off any and all goof assed desktop animations as when I click on a menu I want it open NOW, not five seconds from now… I move a window I want it to move NOW showing me what the window will look like, not with some goofy ‘jiggle’ animation… I hit minimize I want the window minimized NOW. Not to sound like a 14 year old Picard, but “NOW, NOW, NOW, NOW, NOW!!!”
At the same time I agree with some of it… it’s like a hodge-podge of good ideas used to draw some really WIERD conclusions. Smacks slightly of someone starting with their own set of conclusions and then molded the facts to fit them.
That and it’s news to me that Meyer invented them - and I half suspect it would be news to him too – though that would have been what, 2001ish? (and at the time undeployable real-world?). Lemme guess, is that like Edison “inventing” the light bulb?
My real issue with the page though is it not only using javascript, but wasting 13k on it. Could be worse though, could be done in jquery where as ‘easier/faster’ to develop it would end up 20+K for the same functionality on top of needing a 120k library.
Increasingly with large sites what I’ve done is forget all that nonsense exists, and just break it into categories and just use by-page by-section drilldown through the site. People get too obesessed with linking every single sub-page off the main page, and that’s just a waste of time and can result in information overload. (even that article mentions that).
When I was in the Air Force we had the term “Situational Awareness” - it referred to a pilots ability to handle the information being fed them. Information overload was a constant concern as technology provided more and more data - filtering down that data and presenting it in a useful format was always the number one concern.
In that way, deep nested menus or even hordes of links to every page presents too many choices to the user; It’s information overload. On another site a user was bragging about his CRELoaded based sites - I took one look and went “what is this trash?” as every page had over 200+ links on it; Like a user is going to be able to even make sense of that.
Look at E-bay for a great example of reducing the problems with endless pages and sections. Their dropdown menu only lists categories and a few more popular sections from each category - AND you can navigate the ENTIRE site without javascript using standard old-fashioned drilldown.
The biggest problem with flyout menus is nesting them too deep - you need more than one flyout, you are probably doing something wrong, bloating out each page unneccessarily, and it’s going to break somewhere. Don’t overcomplicate things by putting tens or even hundreds of links into a cascading menu - at that point break it up a little. Look at the examples on that page you linked to - FIVE DEEP on the flyouts? **** that and **** any site that does that. (and no, that’s not the word filter, I typed those asterisks myself)
Not a bad solution, but not a great one either. I probably would just have the categories listed on the main page, and then have a drilldown on each category. Again, linking to EVERY page on the site FROM every page on the site? Be a miracle if anyone can find anything.
If you really feel the need to have a page with every link on it, that’s what a sitemap page is for. Don’t waste your time or mine putting a sitemap on every page 
(yes, vBull 4 developers, I’m looking at your garbage when I say that)
The operative word in the quote is “pure”.
There is nothing wrong with having an enhanced menu for those with javascript enabled and a functional mega-list menu for those without. They might get an “ugly” version (that takes up the entire above “fold”?), but as long as it works, it’s accessible.
I think Alex deliberately used a provocative example to drive home his point. It’s a well-used rhetorical tool, and doesn’t necessarily mean that he equates inaccessible websites with murdering children. 
It depends. If there is an alternative way (even if it is somewhat less user-friendly) to achieve the same thing without JavaScript, then it’s not inaccessible.
But if the menu is critical for the use of the site and there is no alternative for non-JS users, then it is inaccessible.
In some cases such a JS-only menu can be used as progressive enhancement, as a ‘reward’ for users who have support for the latest and greatest.
Yeah, that’s a bit more logical and a down to earth.
I am one hundred percent behind the point you’re making, but feel that the high levels of emotion that this question seems to have caused are obscuring the issue somewhat.
Talking of accessibility: is a menu which only functions if JavaScript is enabled count as inaccessible, or is this more a choice of the user (i.e. more of an availability issue)?
Yeah, right. This statement is quite balanced and in no way over the top.
All things in perspective, surely.
Put it like this then:
If you had three children, each one with a different disability, which one of your children would you like to be able to access the web site you’re making for them?
I have a couple of sites with a fair bit of content and am often thinking about the best way to organize the site navigation. It seems to me rather impossible to make all of the content which would be accessible from a dropdown menu, also accessible without it (when JavaScript is turned off).
Thoughts?
Our very own YuriKolovsky actually created a pure CSS dropdown menu (using margins lawlz!), so even IE6 is taken care of. There was a bit of hassle with little things in various browsers but one could go ahead, copy the code and just use it in the real world.
The other way is of course what (Mitt? I forget who said it) mentioned: if the main-levels can be clicked to somewhere that has regular content links to the same stuff that’s in the subs, it’s accessible whether the dropdown menu appears or not.
I coded most of this site but didn’t design it. The designer conveniently left links in the main body of each page so that I didn’t have to worry all that much about whether the dropdowns worked or not. Making someone click 15 times to get to a link they could have gotten to directly via a dropdown is not very good, but one extra click? That’s totally cool with me.
P.S. Should probably mention I settled for accordion style navigation, where the whole thing unfolds as soon as JavaScript is turned off, and al the links are accessible.
Amazon did this, dunno if they still do. I happily buy stuff on Amazon all the time and I don’t surf with scripts on. At one time there was a vertical expansion menu and I just always saw it open, all the time. As Crusty mentioned, the trick with something as big as Amazon is, just show main categories when you do that, if the total number of links is that bad. Which is similar to having main-level anchors work and can take users to somewhere where they can choose further/deeper.
Really, nothing wrong with having Javascript in a menu. I use Javascript in some dropdowns to increase keyboardability (showing the whole sub when any a inside is :focussed) and having a mouse-off (no, Crusty, not a mouse-on, just a mouse-off) delay for people with sh*tty mice like my husband has (you cannot click a checkbox with his mouse, it’s just not controllable… great for testing palsy and motor issues on a site!).
Although if you have the Mega style dropdowns, because they are so large and take up so much space on the page, Jakob Nielsen recommends having a hover-on delay as well, to prevent giant bits of SUBS covering up the page simply because you were trying to move the mouse up over to the login section or whatever. Like Crusty, I like my menus to appear NOW and I like the foto I clicked on to appear NOW (not after waiting a half minute for the lightbox to spin and grow and dance for me) but delays have their place in increasing usability as well. (If you were in the JSLive course, it was mentioned for the JS-tooltip exercise, a mouse-on delay to prevent annoying popups just for moving your mouse across the screen, similar to real browser tooltips.)
Yes, on the one hand, I would agree that :hover is far superior to using javascript to drive menus. The menu functionality is essentially a CSS function and you only want it to drop down and go back when CSS is active. For instance, JS based menu drivers land you with some really weird behaviors if CSS is available but JS is not (or vice versa).
On the other hand, I think we should reiterate Tommy’s point. The purpose of accessibility is not to create “least common denominator websites” where every component is fully accessible. That’s a pretty harsh restriction. The goal of accessibility is to ensure that all content in the site is available.
For example, an audio recording probably isn’t accessible for the deaf, while a video probably isn’t accessible for the blind, while a transcript probably isn’t accessible for dyslexic visitors. However a combination of these strategies would ensure that that the INFORMATION is available to all. I think we should remember, THAT’S the goal of accessibility.
This is one of the reasons I disagree with the requirement that video have synchronized captions. Given the technology available on the internet, I know of no way to do closed captioning which means that you have large lettered open captions on most “accessible” video. This does not take into consideration that there are alternate ways to present the same information via different media. That’s a guideline that violates the spirit of the “if it’s not accessible, present your content in a different way”. That’s a guideline that says “Sorry you have to find a way to make that video work for everyone.”
AFAIK, those laws only apply to the governmental sites, not to private sites. So for private companies, it’s a matter of what percentage of your audience are you willing to ignore?
And as to your last point - it is professional, but a cost/benefit factor does come into play. How many man hours will it take vs the percentage of your audience?
Similar to the language offerings - should a site intended for a 99.9999% Chinese audience offer French, Spanish, German or English versions? Should a company spend hundreds of man hours of effort for a small handful of users a year?
I am new to the forums, but I have several sitepoint books (both hardcopy and pdf), and have always been glad of the support offered. What I’m saying is, I’m a friend not a foe.
My reply ~ in the UK and the US catering for all disabilities on websites is required by law. So why ask the question? Instead ask yourself these questions.
IMHO, disregarding the law is simply not professional. It’s your job, so do it.
Nick
My first wife (an audiologist) said much the same thing. The mistake people make is to assume that because their reading skills are poor, they must be stoopid. Not the case. I’ve seen something of that attitude in some well-meaning (?) accessibility articles: “We need to design down to those poor slobbering idiots so they can gawp at our sites too, the poor dearies.” Hmph.
Needlessly cryptic and slow as molasses is fun? Oh wait, I do still own a trash-80 Model 4p…
[ot]
People say it’s easier, I find it the exact opposite… Kind of like Ruby.
The point of doing Ruby was supposed to be for the fun, not for the speed : )[/ot]
That’s true for a site with an international audience, and perhaps for a geographically vast country/region like the United States, too. But for a country like Sweden it would work. We have a united, standardised sign language throughout the country, afaik.
There is no level of writing that fits everyone. Legalese or other jargon is hard or very hard for everyone except experts. ‘Normal’ prose like in a regular novel down to the newspaper level works for most, but not all. Simplified prose, like Easy English, helps some with reading difficulties but is actually harder to read for a ‘normal-skilled’ reader than normal prose.
From what I understand, it is much harder to learn how to read for a deaf child than for a hearing child. It has nothing to do with intelligence at all; it’s just that a hearing child can associate the letter forms with sounds, which makes it much easier to understand and remember the spelling. Plus the sign language vs spoken language differences.
Those who become deaf after having learned how to read will have no more problems reading than hearing people, of course.