CSS Dropdown Menus and Accessibility

A couple of years ago, I learned how to make these really simple, yet cool looking Drop-Down Menus using only CSS. (It seems to me that it just used the <ul> and <li> tags and would change the background color depending on which item you hovered over.)

Ironically, I never ended up using the Drop-Down Menus after all.

Since then, there have been a few times where I was thinking of using this approach, and I recall Ralph speaking up and shooting down the idea because he said that things weren’t supported by Mobile devices.

Can someone help me understand what all of this is about? (Um, I’ve never owned a Cell-Phone or Smart-Phone, so I’m clueless on how that technology works!!) :blush:

Since I was just using HTML and CSS - with no JavaScript - you would think that this approach would be supported on nearly every platform, but maybe not?!

Sincerely,

Debbie

Mobile devices don’t have a mouse, of course, so you can’t hover over an element—which is often what a dropdown relies on. Some devices do sort of open the drop menu if you touch the link, so they are not totally inaccessible. I guess you have to do some testing.

There are various other reasons why drop lists can be inaccessible. Not everyone uses a mouse, so it’s good to ensure that the menu links can be accessed via the keyboard. This is often not the case. An argument against CSS menus is that the drop menu doesn’t linger on the screen momentarily if the mouse strays away from it (which can easily happen if your hand is a bit shaky or whatever). JS drop menus often have a built in delay, so that the drop menu doesn’t disappear immediately if the mouse strays, and also the menu doesn’t appear instantly if the mouse inadvertently strays over the menu when you didn’t want it to.

Drop menus are also sometimes set to display: none until they are hovered. This can mean that someone using a screen reader won’t be aware of the sub menu at all. That’s fine if there is an alternative menu in each section, but a disaster if the submenu is the only means of accessing subordinate pages.

I thought with Smart Phones - like the iPhone - you could rag your finger and it was treated like a mouse? (For example, if you dragged your finger over this menu I created, then as your finger moved across each Section, a Sub-Menu would appear. Then if you chose one of those Sections and dragged your finger down the SUb-Menu, each item in the Sub-Menu would appear highlighted as your finger went over it - just like how a mouse behaves. No?)

There are various other reasons why drop lists can be inaccessible. Not everyone uses a mouse, so it’s good to ensure that the menu links can be accessed via the keyboard. This is often not the case.

Can that be achieved with CSS only?

An argument against CSS menus is that the drop menu doesn’t linger on the screen momentarily if the mouse strays away from it (which can easily happen if your hand is a bit shaky or whatever). JS drop menus often have a built in delay, so that the drop menu doesn’t disappear immediately if the mouse strays, and also the menu doesn’t appear instantly if the mouse inadvertently strays over the menu when you didn’t want it to.

Yes, I’m aware of that.

Drop menus are also sometimes set to display: none until they are hovered. This can mean that someone using a screen reader won’t be aware of the sub menu at all. That’s fine if there is an alternative menu in each section, but a disaster if the submenu is the only means of accessing subordinate pages.

So how would you handle this in CSS only?

Sincerely,

Debbie

I don’t think so (not in my experience anyway) but if you lightly tough a drop link, the drop menu sometimes appears and its links can be clicked, though it’s hard to get rid of them again if you don’t want to make a choice.

Can that be achieved with CSS only?

Yes, to some extent. Deathshadow60 produced an interesting example a while back (although it doesn’t seem to respond to keyboard so well now … so somethings changed. Edit: that’s probably not the right link. The original thread where this was discussed is [URL=“http://www.sitepoint.com/forums/showthread.php?767633-cascading-menus-new-way-doing”]here, so perhaps that gives a clue to the code that was being employed.)

So how would you handle this in CSS only?

Rather than display: none, you can move the menu off screen with a negative left margin or similar until its parent is hovered.

it can if the browser supports focus, however I think for Phones you’d prolly still need a TouchEvent.

What I was able to come up with for completely keyboardable dropdowns was, on hover or focus of the main menu item, the submenu would appear (like with a mouse)… that part’s easy. But then I had it that each anchor in the submenu, when focussed on, also came onscreen. Without Javascript I could not keep the whole submenu onscreen but it was usable, if not super nice, using focus.

When using focus I found I needed to set px as the unit, rather than em. I’m not sure why. Also I usually had to re-state things like background colours and widths on these anchors, which I didn’t have to do for the hover-related code. Then I layered some Javascript on it to make submenus stay onscreen while tabbing through submenus.

I would not use this setup if the submenu was large. I’ve started liking the display: none more, because a huge menu before the content is a whole lotta tabbing. But, as Ralph said, this is acceptable only if clicking on top-level items brough you to a page with the submenu options… meaning without being a pain in the butt, users could still pretty much get to everything.