RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Hi Mathew, http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp I have a bug report... tested against FF 3.6.4 and IE6 (no bug under Chrome 5.0.376) Steps to reproduce: - click on background - tab to focus first menu item - hit enter to display sub-items - tab through to the second menu - hit enter to display its sub-items (the first menu closes) - hit shift-tab to go back to the first menu The bug is either one of a) the first menu shouldn't open as the second menu is active, or b) that the second menu stays open. Thanks for the step by step, but unfortunately I cannot reproduce (in neither one of these browsers). Could somebody confirm the issue following the steps above? Thanks. As a side note, there is something strange in these steps as the first menu should close before you can even hit enter on the second one. Are you sure you do not have your mouse cursor over the first tab while checking the menu? Because that would explain what you describe. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Sorry Thierry I only took a quick look at the page and didn't read it fully. Mike -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Thierry Koblentz Sent: 29 June 2010 17:34 To: wsg@webstandardsgroup.org Subject: RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu) Hi Mike, Sorry to say this but the keyboard friendly version: http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp Only fires, via keyboard, on Articles E-K in IEv8 or Firefox. This is by design. Keyboard users could not reach these pages if they were not focusable at least from the parent page. The About this solution section says: Note that keyboard users cannot skip the sub-menu related to the current page. This is because this sub-menu is exposed to SE (Search Engines) and thus accessible to keyboard users when JS is off. The sub-menus open via the *enter key*, this is to allow keyboard users to skip sub menus so they are not forced to tab through all the menu items. If the menu is accessible, it is *because* the sub menu related to the page itself *is* focusable (it is not styled with display:none). What this menu is missing though is a arrow pointer for *discoverability*. I have a title in there, but I think it's pretty useless (for 99.99% of users). If I had time, I'd add arrows and ARIA roles too. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** This is a confidential email. Tesco may monitor and record all emails. The views expressed in this email are those of the sender and not Tesco. Tesco Stores Limited Company Number: 519500 Registered in England Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 9SL VAT Registration Number: GB 220 4302 31 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
On 29 Jun 2010, at 00:30, grant_malcolm_bai...@westnet.com.au wrote: I'm trying to avoid use of Javascript due to accessibility concerns. Trying to shoehorn functionality (which is what JS was designed for) into CSS (which is designed for presentation, not logic) is not good for accessibility. The classic example is the drop down menu which, if built using :hover instead of JS: * Can't respond to navigation without a pointer (e.g. keyboard tabbing, or a breath switch) * Can't have any 'fuzz factor' around the pointer position and timing of when a menu goes away (so if someone has any trouble at all with motor skills (e.g. because they have arthritis) they they could find it very different to get to the bottom of a menu without sliding outside it for a second and losing it) * Can't work in IE6 (since it's support for :hover is poor) (at least not without using a really evil hack involving conditional comments and layout tables). JavaScript is not the enemy of accessibility, it just has to be handled with care. If you are worried about pages breaking if JS is not available, then build on things that work: http://icant.co.uk/articles/pragmatic-progressive-enhancement/#build -- David Dorward http://dorward.me.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Hi everyone, Can everyone suggest which CSS/JS horizontal and vertical drop down navigation they would recommend? Thanks, Elaine Wildash Web Dandy Twitter: http://www.twitter.com/webdandy www.twitter.com/webdandy Facebook: http://www.facebook.com/pages/Web-Dandy/171945798743 www.facebook.com/pages/Web-Dandy/171945798743 _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of David Dorward Sent: 29 June 2010 07:15 To: wsg@webstandardsgroup.org Subject: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu) On 29 Jun 2010, at 00:30, grant_malcolm_bai...@westnet.com.au wrote: I'm trying to avoid use of Javascript due to accessibility concerns. Trying to shoehorn functionality (which is what JS was designed for) into CSS (which is designed for presentation, not logic) is not good for accessibility. The classic example is the drop down menu which, if built using :hover instead of JS: * Can't respond to navigation without a pointer (e.g. keyboard tabbing, or a breath switch) * Can't have any 'fuzz factor' around the pointer position and timing of when a menu goes away (so if someone has any trouble at all with motor skills (e.g. because they have arthritis) they they could find it very different to get to the bottom of a menu without sliding outside it for a second and losing it) * Can't work in IE6 (since it's support for :hover is poor) (at least not without using a really evil hack involving conditional comments and layout tables). JavaScript is not the enemy of accessibility, it just has to be handled with care. If you are worried about pages breaking if JS is not available, then build on things that work: http://icant.co.uk/articles/pragmatic-progressive-enhancement/#build -- David Dorward http://dorward.me.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***image001.gif
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
I find it's best to do your homework, and shop around. There are so many options and paths you can go down, and with things changing rapidly so often, something that works today, may not work so well tomorrow. Sitepoint is a good start, they publish a good book By Rachel Andrews, CSS Anthology, currently 3rd edition. She recommends a Javascript version for accessibility. I would agree. Best of luck on your journey . . . John -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of David Dorward Sent: Tuesday, 29 June 2010 8:22 PM To: wsg@webstandardsgroup.org Subject: Re: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu) On 29 Jun 2010, at 11:04, de...@littlegent.com wrote: I'd recommend using one from http://www.cssplay.co.uk/menus/ The trick is deciding which one to use, really. =) Having taken a quick look, I'd run a mile from them. The first one I looked at was missing and pointed me somewhere else, which assured me that I've love a newer version and directed me to http://www.cssplay.co.uk/menus/final_drop.html It was wrong, I don't love it. It seems to have all the problems I described earlier (although it does, at least, bother to have basic links at the top (I wonder how many people bother to put something useful that that can substitute for the menu on those pages...) lia href=../menu/index.htmlDEMOS!--[if gte IE 7]!--/a!--![endif]-- !--[if lte IE 6]tabletrtd![endif]-- This hideous excuse for markup can't be worth removing the dependancy on JS, can it? (Especially since you need to implement the same fallbacks anyway!) -- David Dorward http://dorward.me.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
I used to use cssplay menus 6+ years ago but they're not the friendliest or most compliant to work with. I really like superfish - i've been using that for a few years with no problems at all. and I find it very easy to customise. http://users.tpg.com.au/j_birch/plugins/superfish/ I haven't really drilled down on it but it degrades nicely - works well in IE without any weird conditionals - and all my sites are XHTML strict compliant. - daniel hellodan...@mac.com On 29/06/2010, at 8:21 PM, David Dorward wrote: On 29 Jun 2010, at 11:04, de...@littlegent.com wrote: I'd recommend using one from http://www.cssplay.co.uk/menus/ The trick is deciding which one to use, really. =) Having taken a quick look, I'd run a mile from them. The first one I looked at was missing and pointed me somewhere else, which assured me that I've love a newer version and directed me to http://www.cssplay.co.uk/menus/final_drop.html It was wrong, I don't love it. It seems to have all the problems I described earlier (although it does, at least, bother to have basic links at the top (I wonder how many people bother to put something useful that that can substitute for the menu on those pages…) lia href=../menu/index.htmlDEMOS!--[if gte IE 7]!--/a!--![endif]-- !--[if lte IE 6]tabletrtd![endif]-- This hideous excuse for markup can't be worth removing the dependancy on JS, can it? (Especially since you need to implement the same fallbacks anyway!) -- David Dorward http://dorward.me.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Try this for CSS menus with keyboard support: http://carroll.org.uk/sandbox/suckerfish/bones2.html This menu may be accessible, but is it usable? Unless I am missing something, keyboard users need to go through *every single link* in the menu to reach the last item :-( I have these two: http://tjkdesign.com/articles/new_drop_down/default.asp http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp They show what's involved and what are the limitations. Pure CSS menus are a bad idea, and hybrid implementations that claim to be accessible simply because links are accessible are often bad solutions too. Imho, users should be able to access all pages within a web site without frustration. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Hey Thierry, Sorry to say this but the keyboard friendly version: http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp Only fires, via keyboard, on Articles E-K in IEv8 or Firefox. Mike -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Thierry Koblentz Sent: 29 June 2010 16:22 To: wsg@webstandardsgroup.org Subject: RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu) Try this for CSS menus with keyboard support: http://carroll.org.uk/sandbox/suckerfish/bones2.html This menu may be accessible, but is it usable? Unless I am missing something, keyboard users need to go through *every single link* in the menu to reach the last item :-( I have these two: http://tjkdesign.com/articles/new_drop_down/default.asp http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp They show what's involved and what are the limitations. Pure CSS menus are a bad idea, and hybrid implementations that claim to be accessible simply because links are accessible are often bad solutions too. Imho, users should be able to access all pages within a web site without frustration. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** This is a confidential email. Tesco may monitor and record all emails. The views expressed in this email are those of the sender and not Tesco. Tesco Stores Limited Company Number: 519500 Registered in England Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 9SL VAT Registration Number: GB 220 4302 31 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Hi Mike, Sorry to say this but the keyboard friendly version: http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp Only fires, via keyboard, on Articles E-K in IEv8 or Firefox. This is by design. Keyboard users could not reach these pages if they were not focusable at least from the parent page. The About this solution section says: Note that keyboard users cannot skip the sub-menu related to the current page. This is because this sub-menu is exposed to SE (Search Engines) and thus accessible to keyboard users when JS is off. The sub-menus open via the *enter key*, this is to allow keyboard users to skip sub menus so they are not forced to tab through all the menu items. If the menu is accessible, it is *because* the sub menu related to the page itself *is* focusable (it is not styled with display:none). What this menu is missing though is a arrow pointer for *discoverability*. I have a title in there, but I think it's pretty useless (for 99.99% of users). If I had time, I'd add arrows and ARIA roles too. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: Using CSS instead of JS for accessibility (was Re: [WSG] CSS Expandable Menu)
Sorry to say this but the keyboard friendly version: http://tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp Only fires, via keyboard, on Articles E-K in IEv8 or Firefox. This is by design. Keyboard users could not reach these pages if they were not focusable at least from the parent page. The About this solution section says: Note that keyboard users cannot skip the sub-menu related to the current page. This is because this sub-menu is exposed to SE (Search Engines) and thus accessible to keyboard users when JS is off. The sub-menus open via the *enter key*, this is to allow keyboard users to skip sub menus so they are not forced to tab through all the menu items. If the menu is accessible, it is *because* the sub menu related to the page itself *is* focusable (it is not styled with display:none). What this menu is missing though is a arrow pointer for *discoverability*. I have a title in there, but I think it's pretty useless (for 99.99% of users). If I had time, I'd add arrows and ARIA roles too. I have a bug report... tested against FF 3.6.4 and IE6 (no bug under Chrome 5.0.376) Steps to reproduce: - click on background - tab to focus first menu item - hit enter to display sub-items - tab through to the second menu - hit enter to display its sub-items (the first menu closes) - hit shift-tab to go back to the first menu The bug is either one of a) the first menu shouldn't open as the second menu is active, or b) that the second menu stays open. regards, Mathew Robertson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
