G'day Rafael, On 15/10/2007, at 2:01 PM, Rafael wrote:
> I think this is yet another religious topic. Accessibility on > most JS menus (actually all I've seen so far) is inexistent, some > of them are so poorly done than they even throw an error on this or > that browser and the whole menu stops working. If you ask Joe Clark > about his opinion... maybe he would trash both of them :) I think in the authentic meaning of the word 'Accessibility', well- produced JS menus far outshine CSS-only ones, if only for point 2 of my previous email (introducing delays before collapsing submenus). As for handling errors and browser support, of course that's all down to implementation (any good JS is totally unobtrusive and so only users with support get the advantages of the Javascript). > Personally, I think CSS menus are better (or "less bad") than > JS menus. In both cases you must know what you're doing and have > accessibility on mind (and hoy many of us do really do this?). If > you ask me, a combination of both is the best solution, which means > a lot more work than current / typical implementations --and the > client's can't see a reason to spend on that, and the guy doing the > front-end has a lot of things to think on before spending some > "extra time" on the "minor details". I like to think I keep accessibility on the mind throughout every phase of a frontend design job. I do testing in text browsers, and in upwards of 10 desktop browsers (including the big four; IE 6, IE 7, Firefox 2 and Safari 2). When you say "a combination of both", that's exactly the behaviour I'm talking about when I say 'Javascript menus'. I don't believe in pure Javascript implementations of anything. It must be loaded unobtrusively as a supplement (rather than replacement) of CSS-based menus. As a full-time 'frontend guy', navigation is around about number 3 on my list of priorities when putting together a website; I think part of calling ourselves professionals is treating every part of each job as worth our time. Plus drop-downs tend to feature in around 90% of the designs our Art Director puts together, so getting it right once helps us with subsequent jobs. > I myself should be redoing part of a menu I'm planning on > using, but is for a personal site so the time I have spent on it > is... a message I sent to this list (and that Georg kindly > replied), that's all. Oh, well... real life again. In case you're > curious, the link I sent was > http://dev.rsalazar.name/css.d/menu.html > By the way, the best solution for the accessibility issue I asked > help for seems to be a re-implementation of the CSS "behavioral" > part combined with a little JS to make things look better (ironic? > yes, it is). I like the way that's looking, but it shows off exactly what problems pure CSS menus always (necessarily) show: say you expect another level of navigation to drop down, or you're just not particularly good with a mouse. You go to Groupo D, Groupo D.2, Enlace D.2.a and slide your mouse off the bottom (just a pixel) and instantly all progress is lost and you have to start from the top-level again. This is more important still when you have many items in each menu level (since there is more cognitive thought required to decide a menu item). > Here are some opinions, if you mind... > > Kit Grose wrote: >> G'day Jay, >> >> I've heard the request for pure CSS drop-down menus quite a lot, and >> rarely see people getting told what they should about how *bad* they >> are. >> > Can you say better things on JS menus? Aren't basically the > same things? No! Javascript adds some more desktop-level comforts to the way things work (like menu hide-delays). >> CSS is designed as a method for styling visible items and laying them >> out relative to one-another. Drop-down menus are behavioural, and >> thus should be taken care of with Javascript (not Java; there's a >> huge difference, worth noting). Of course, accessibility means >> keeping in place a series of fall-backs which allow non-JS enabled >> users to view the list. >> > So would CSS fall-backs to do exactly the same. Yes, but they're fall-backs. Just as the fall-back for no CSS is a simple nested unordered list, we have to draw the line somewhere. We lose some usability, but it still works. > It's hard (for me, at least) to agree on using JS solely on the > fact that their behavioral and, therefore, should be done with JS. > It's kind of the same as saying that changing the colors is a > behavior, not a style (which would be correct), or saying that > pseudo-elements and pseudo-classes have no reason to exist, since > they're referring to a behavior or somehow altering the DOM. Changing the colours based on user interaction (like hover/mouseover) is indeed a behaviour, but unless we need animation, we're able to hand that job off to the stylesheet (via :hover). Pseudo-classes and elements should exist for purely stylistic purposes in things such as :first-child getting a drop-cap or different border, etc. I'm fairly pragmatic in my usage of what's available to me when I'm working: a:hover is clearly a good thing to tap into, because it's available to us in every (modern) browser. If good drop-down menus were as simple as show on hover and hide on mouseout, I'd be pretty happy with CSS-only drop-down menus (once IE supports the child selector). I don't, however, agree that a menu should be so touchy (I don't know if you remember the system-wide menubar in Mac System 6, but it behaved quite similarly, albeit requiring a mousedrag instead of a hover. They changed it from OS 8 or so onward to behave more like Windows, where a user opened a menu and closed a menu as separate actions, which worked very well for people who aren't particularly dextrous; while I'm not suggesting web interfaces should mirror the desktop 1:1, I do feel we should learn from years of UI development in that field). >> There are some massive accessibility gains that Javascript drop-downs >> provide: >> • You can animate opening and closing lists (not just eye-candy; it >> makes it very clear to the user when there is a change on the screen) >> > Just like Flash... wouldn't really want to go more in-depth on > this (another religious topic). Noone decides they don't like Flash on account of its animation ability; heck, that's one of its best uses. People (in our industry) dislike how poorly it integrates into the rest of the page and user environment (keyboard access, for instance, as well as assistive technologies). Animation is a useful indicator of change to an enduser if it can be incorporated in a way that doesn't sacrifice accessibility. >> • You can provide a suitable pause before the list collapses (your >> users are not necessarily skilled with a mouse or keyboard. They may >> have difficulty operating a mouse and I can tell you from experience >> that they have real difficulty changing movement from horizontal >> (along your list headings) to vertical (down your first level list >> items) to horizontal (across the list item to the sublist) to >> vertical again (down the sublist items) without accidentally moving >> the mouse out of the bounds of the list item. Javascript menus >> introduce a delay before actions are cancelled so that a slight >> movement of the cursor outside the bounds of a list item is not >> penalised against) >> > Granted. I agree on this, the menu I mentioned before is > actually a vertical-vertical variant instead of the common > horizontal-vertical versions. I've touched on it briefly, but while your type of menu is better, it still requires much higher skill for my grandma to use than a menu augmented with Javascript >> • You can get identical behaviour in all the major browsers (all the >> CSS-only drop-down menus rely on CSS hackery to work properly in IE. >> Every sensible browser can handle the ul>li selector; the basis of a >> simple, standards-based CSS solution, but IE doesn't. CSS hackery is >> no better for you as someone who doesn't understand JS but does >> understand CSS than JS hackery; CSS hacks commonly *don't make >> sense*. They're backward thinking and complex to write). >> > Mhh... I can't see JS being more standard than CSS right now (I > guess it depends on the versions). JS has been out there more than > CSS, but it seems they're standardization isn't that far from each > other. ECMA script and DOM implementations aren't quite well > supported yet, not to mention the combination of CSS and dynamic > elements. Yeah, I agree, Javascript has its own set of standards issues, but they're isolated from the rest of the website (if coded effectively). The advantage there is that library or script developers can do a lot of testing cross-browser and distribute the code unchanged to work across most website layouts. It means, too, that if the developer is informed of particular bug in the code it can be fixed and the JS can be updated trivially across all the sites we deployed the JS file on. > By the way, CSS hacks make sens to those who know and > understand CSS, just like JS hacks (don't tell they don't exist, > please) makes sens to those who know and understand JS. Yet again, > a religious topic. I love me some CSS hacks! The best one (to my mind) is the simple underscore hack (_width is evaluated by IE as width). My only reason for bringing it up was that the OP said they didn't understand JS, but did understand CSS. If you're having to mess with CSS hacks just to get functionality then you're walking a fine line with browser support anyway, which I think everyone agrees we'd all rather not do. >> Please, for your users' sake: use a Javascript drop down menu (but >> make sure it's one that is fully accessible, and that reverts to a >> pure-CSS menu when JS is not available). I use TwinHelix Designs' >> excellent FreeStyle Menus (http://www.twinhelix.com/dhtml/fsmenu/) >> personally, but it's donationware for commercial use. >> > Nice... but I can't see the advantages on accessibility / > usability on it. Would you mind telling me about them? The menu allows keyboard navigation, poor motor skills (mouse sliding on and off the menu), and great browser support, all the while reverting back to a pure CSS menu when JS can't be loaded. Plus I still feel animation allows for better usability for (particularly non technical) users as an indicator that something has changed on the screen (and that there's more options to scan). > Clarification: When I say "religious topic" I don't mean any > harm or an insult in any way, it's just that all religions *I've > heard of* are something you trust on, that you have faith on, you > don't evaluate them or demand proves, you believe in them and > defend them --I didn't want to use "dogma". I don't doubt that it's a touchy topic! I love the debate and constantly try to reaffirm my choices across clients' websites. Cheers, Kit ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
