Tab navigation on Drop-down menu

I recently discovered that the drop-down menu on a site is totally unnavigable using the tab key. I got as far as making the drop-down appear when its header gets focus, but then hit a brick wall. I need the drop-down (a nested ul) to stay visible while its contents (<li><a></li>) are tabbed through and have focus. I just can’t seem to find the right css selector to make this happen. I don’t know of a selector that selects a parent of an element with focus, is there such a thing?
The menu works purely on css, no js, I would like to keep it that way if possible.
The site is here and I also knocked up a Pen to isolate the relevant code so it’s easier to find and play with.
http://codepen.io/SamA74/pen/ojKBNy

I still have not come up with a proper solution to this, but have improved it slightly. Hiding the drop-downs with an off-set left:-999em instead of display:none, as per this, which claims to be Accessible, makes them “visible” to screen readers at least, which is better.
But what about seeing users who use tab navigation? They won’t see the drop-down links which have focus.
On the other hand, I have been thinking about giving the site a full code/style overhaul, but it seems a daunting task. I was experimenting with some “concept” menus systems. I have a dummy example page with a new menu. It appears fully tab navigable while being in vision and is fully responsive down to a silly small size without any media queries. My only concern with it is weather some touch-screen users may find the icons a bit cryptic since they don’t see the labels on hover. But then it’s no big deal just to tap and see. This is probably not the design I will use in terms of styling, it’s more about the functioning of it. Any comments? This is the dummy page.

I, too, would love to see a solution to this. Most of my sites are very small and don’t require a drop-down menu. When I ran into one which did, I hunted high and low for a solution, but the best I could do was to adapt the Sons of Ursidae menu. It’s not ideal; only the focussed item from the drop-down appears, hovering in splendid isolation. The really sad thing here is that, as a regular keyboarder, I can confirm that is a vast improvement on many of the sites I visit.

[quote=“SamA74, post:2, topic:208606”]
I have a dummy example page with a new menu. It appears fully tab navigable while being in vision and is fully responsive down to a silly small size without any media queries. My only concern with it is weather some touch-screen users may find the icons a bit cryptic since they don’t see the labels on hover.
[/quote]I found that page a bit disconcerting at first glance, because there didn’t seem to be a navigation menu at all. (I was looking for a “traditional” text-based menu.) I’m never a fan of using images (or icons) in place of text (whether on a website or in flat pack instructions ), but once I got used to it, I quite liked that menu. It’s certainly keyboard-accessible.

I thought is was just me being clueless about making accessible menus.

I was quite pleased with this menu idea. But I had doubts about people being confused by only seeing icons to begin with, so wanted some feedback from others. I think it is certainly better with regard to accessibility and responsiveness. Though as mentioned, touch-screen users won’t see the hover/focus labels, but maybe phone users are used to hamburgers and would ‘get it’.

It may, of course, just be both of us being clueless…

But as I say, remarkably few sites cater for keyboarders at all. (I was surprised to discover that in some quarters, keyboarding is regarded as a “power user” issue, rather than an accessibility issue.)

[quote=“SamA74, post:4, topic:208606”]
Though as mentioned, touch-screen users won’t see the hover/focus labels, but maybe phone users are used to hamburgers and would ‘get it’.
[/quote]I don’t own a touch-screen device, but I don’t think it’s any more onerous for a user to touch an icon to see what it is than it is for someone to hover on it or tab to it.

I made something long long ago (needed to work with IE6 at the time) where you could tab through everything.
http://stommepoes.nl/Emo/

I’m nowadays more personally in favour of using JS and display: none-ing the submenus so people don’t have to tab through possibly a bazillion submenu items to get past the menu (where, if no JS, the whole menu is available plus skip link), but for a pure-CSS solution if the menu itself isn’t too ginormous… this could work.

Edit: seems even that example is using JS, I thought when looking back that the JS here just made hover more sane… nope.

Without JS, the currently-focussed element does appear, but not the whole submenu.

I have since put the new menu (with further modifications) onto to the actual site.
I’m very much a mouse user, and find it a little more awkward than the old drop-down, but I’m putting that down to it being less familiar to me.
The new menu does seen much more “tabable” to me, as a non-tab user.
Any feedback?

As I have it now, you only have to tab through the menu headings, you only get the sub-menu if you select a heading.

Hm, once I’ve hit enter and I see there’s a submenu, my focus has been brought back to the top-- though eventually I can get to the submenu.

(oh this might be the browser bug- firefox does the right thing here, Blink and Webkit and IE browsers won’t move the keyboard focus to a destination-- the current solution to that is either to manually move focus with JS or just add tabindex="-1" to the element whose ID you’re targetting with the link.)

However like mousers, it’s not uncommon to look at a submenu simply to see what’s available, but I had to play around with it to realise I needed to select another menu items to see new subs.

The page also goes dark-- how do I make it light again if I end up not wanting to select a submenu item?

After playing around with it for a bit, I can figure out most of it. If I were visiting regularly I’d probably be okay.

It’s pretty good for pure CSS, though it’s also why I’ve started likeing JS’d menus (where I can do things like control the focus, make the submenus either disappear when tabbing off them or make users cycle through them like an application menu until they decide they don’t want to view the submenu anymore etc). A CSS wizard might come up with some cool stuff to improve the usability but I think it’s a pretty decent CSS-only menu.

2 Likes

That’s an odd one, in Firefox, it starts off where you left off, which is nice. But in Chrome, you are back at the beginning.

Yes, that was showing the menu has focus. It seemed like a good idea at the time, but I’m thinking now it bugs me a bit.

The idea was, when the menu has focus, the page gets a dark tint, it’s actually a menu close link after the menu, when it has focus the page goes light again, you select and the sub-menu goes away.

I’m not that good with js. I’ve dabbled with it, but it’s something I maybe should expand on.
I like the idea of not relying on it for stuff to work, but I suppose it can be good for “additional enhancements” to usability. Though modern css has come some way to negate the need for it in many cases.

Agreed.

One of the reasons I started liking JS enhancements was because I started working with aria-ised widgets (where certain keystrokes are expected to do stuff: example of a tab-panel widget list of requirements, where basically having the aria-roles without the JS to backup the keystroke promises is bad) and so I’d been playing with menus, modal dialogs and the such (I’ve seen some pretty good CSS-only modal dialogs, but accessibility-wise if you’re using Assistive Technology they still have a lot of failings).

Because I’m a fan of progressive enhancement, I’ve been pushing my team to make even these types of widgets (tab panels, but also menu dropdowns etc) work at some level with good HTML, layer it on better with CSS, and finally let Javascript also do things like add in the roles (and use the roles as styling hooks in CSS) so that a user never gets something promising certain keystrokes unless JS is definitely there to do the job. (example)

I’ve made a decent JS’d dropdown menu but it was for my previous company where I couldn’t convince them to make anything work without JS-- so it fails too much for my taste without JS. I ought to see if I can adjust that current menu to do something useful without JS, using more of the CSS abilities (esp as you mention, current CSS offers a lot more than CSS in the heyday of IE6). Using the :target attribute is also pretty awesome.

1 Like

https://github.com/w3c/tr-design/issues/39 mentions the chromium bug

@SamA74 there’s a great javascript tutorial here by a certain @felgall if you’re interested.

Thanks. I will have a go at learning more js at some point.
Though in a strange way it does help me not to use it “willy-nilly” but only when I have to, if that makes sense.

Indeed it does :slight_smile:

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.