Notice: This is a discussion thread for comments about the SitePoint article, Nifty Navigation Using CSS.
“but you’re also locking out text-only devices such as screen readers”
A screen reader is NOT a text-only device, and frankly, it’s pretty sad to see this myth is still being perpetuated. The dropdown menus example will be inaccessible to the most popular screenreaders because they can’t read content which is not displayed. Quite apart from the the fact that such menus are inaccessible to keyboard users.
Pure CSS menus have extremely poor accessibility and usability, and should never be used.
Ok team lets try again as I cant put a link into here of one of your pages :), on your css menu (red,brown) you show main menu items, then sub menu items, is it possible to make it an expanding menu please, so you click on an top level item, then the sub menu opens underneath, then click on an other top level, the previous sub menu closes up, and a new sub level opens…
I was hoping that it was in the book you sell but it was not.
All the best from Alan
The dropdown menus example will be inaccessible to the most popular screenreaders because they can’t read content which is not displayed.
Quite apart from the the fact that such menus are inaccessible to keyboard users.
I’ve heard JAWS read text with display: none; loud and clear. It seems ridiculous to me that a screen reader should look at the CSS in this way, though I don’t doubt that some do actually work like that - I just think it’s stupid.
I’ve used the keyboard to move around CSS only menus fine and dandy,
Pure CSS menus have extremely poor accessibility and usability, and should never be used.
frankly, it’s pretty sad to see this myth is still being perpetuated
A screen reader is not an aural browser, it’s a layer on top of the operating system and its applications. I would guess that a screen reader such as JAWS doesn’t read the HTML or CSS as such, but works with the DOM tree generated by the actual browser (usually IE). In fact, it’s probably not the DOM tree but the rendering tree, which is why elements with display:none don’t appear.
By “pure CSS” I mean menus with only list-item :hover triggers and no additional behavior layer. In order to be useable by mouse users, and accessible to keyboard users, menus need behavioral scripting, to implement things like open/close delays and focus triggers.
The assumption that “works without javascript” == “more accessible” simply doesn’t hold true; the situation is more complex than that.
A screen reader is not an aural browser, it’s a layer on top of the operating system and its applications. I would guess that a screen reader such as JAWS doesn’t read the HTML or CSS as such, but works with the DOM tree generated by the actual browser (usually IE). In fact, it’s probably not the DOM tree but the rendering tree, which is why elements with display:none don’t appear.
interesting, thanks Tommy,
[quote]
I’ve used the keyboard to move around CSS only menus fine and dandy,
Care to show me an example of such a menu?[/quote]
Well… not the sub-menu items without js. I see what you were getting at now, I wouldn’t label it with “extremely poor accessibility and usability, and should never be used.”
I better relax Sounds that Mark already has plans to start WW 3
I should probably clarify my point - I’m not levelling my criticism at all forms of CSS navigation, not at all, and the vast majority of what’s being taught in this article is solid best-practise.
All I’m saying is that CSS is not suitable for defining behaviors - it doesn’t have the capability, and that’s what JavaScript is for.
Pure CSS navigation bars and other static navigation structures:
A great resource I use is Listamatic http://css.maxdesign.com.au/listamatic/ Seems like some of the examples here is taken from there so it’s worth a visit.
