You may have heard that display:none is bad for accessibility and that you should use off-left positioning instead. It isn’t about using display: none; or off-left positioning. It isn’t just about screen reader users. It’s about making an interface work for everyone with efficient keyboard access for everyone that needs it—sighted or not.

Have you heard this before?

If you use display:none, then screen readers don’t get that content. It is better for accessibility to use off-left positioning instead of display:none

The next thing you know, someone has it in their head that this is a binary situation: display:none is bad for accessibility and off-left positioning is good for accessibility.

Here’s the thing, though–sometimes you WANT to use display:none. Sometimes you want to use off-left positioning.

I actually saw an example recently that used off-left positioning and they said right in the comments:

/* keep this off-screen because it is more accessible than display:none */

Off-left positioning is a technique that is often used in image-replacement that allows you to essentially create a text alternative for CSS background images that are used in your designs. It has also been used for other things like hiding menus and other content off the screen–often in the name of accessibility.

The case I saw the other day was using off-left positioning for creating a CSS only hierarchical menu.

Here’s an example of how it was done:

Example of errant use of off-left positioning in the name of accessibility.
Screenshot: Here’s an example of off-left positioning used in the name of accessibility because it is more accessible than display:none even though the implementation is much less than accessible.

http://examples.simplyaccessible.com/css-menu/

There are 4 menu items that have sub-items that show when you use the mouse to hover over the items.

Now, start to tab through that page with your keyboard. What happens when you tab from the “About” link? Let me highlight this for you:

The keyboard focus is placed on the next link (“The Company”) that is still hidden from view because it is hidden using off-left positioning.

The keyboard focus is now invisible to someone that is a sighted keyboard user (remember, screen reader users aren’t the only people that use a keyboard for navigation!). The focus disappears until “Services” gets the focus and then disappears again and again after each main navigational item as the off-left sub-menus have the focus.

Fixing the problem

There are several ways to solve the problem, each of which take into account two key considerations:

  1. Keyboard access to all content for everyone.
  2. Elements that aren’t visible on the screen shouldn’t (generally) be able to receive the focus.

Here are a few options that we’ve cooked up for you to look at. And please, while you’re looking at these examples, go through them with a keyboard (both forwards and backwards) to see the kind of keyboard access they provide compared to the original.

Option 1: use display:none instead of off-left positioning and set the menu such that :focus doesn’t turn it to be display:block. This would require the “landing pages” for each of the top level menu items to have the equivalent sub menu items readily available on the page. http://examples.simplyaccessible.com/css-menu/option-1.php

Option 2: use display:none and have a :focus state to match :hover that makes it display:block and brings the sub menu items onto the page, allowing them to receive the focus, but only while they are on the screen. http://examples.simplyaccessible.com/css-menu/option-2.php

Option 3: use off-left positioning but use :focus to bring it back on the screen. Again, this would bring the sub menu items onto the page and allow them to receive focus, but only while they are on the screen. http://examples.simplyaccessible.com/css-menu/option-3.php

Note: We aren’t going to include an ARIA example here. That’s for another article 🙂

The real problem

The problem isn’t so much that off-left positioning was used. The problem is that it wasn’t used appropriately combined with the faulty assumption that we need to use off-left positioning because it is more accessible than display:none. Someone came to understand through their own experimentation or hearing or reading that display:none isn’t good for accessibility and THEN implemented a solution without thoroughly testing for full keyboard access.

If you’re developing anything for the web make sure that you have efficient keyboard access to everything, and that you’re not allowing the focus to go off the screen to elements that are hidden off-left.

Now that would be better for accessibility.

8 thoughts on “Better for accessibility”

Read comments

  1. Jason Kiss says:

    Great article, Derek, and a useful reminder, for sure.

    It reminds me of a similar situation involving tabbed interfaces (whether or not they implement ARIA) where the hidden/inactive tab panels are positioned off-screen instead of using display: none;. In that case, the keyboard user, sighted or not, ends up being able to access all the links and/or content in the hidden and inactive tab panels, no doubt a confusing situation for the user.

  2. A helpful article. Thanks for laying out the different options.

    I would argue that the original construct is a problem not just for sighted keyboard users, but also for screen-reader users who would have to tab through and hear every one of the sub-menus just to get to “Contact Us” since it is the last of the menu items. This would be especially tiresome on sites with extensive sub-menus.

    I would choose Option 1 for this reason since that problem is still there in Options 2 & 3.

    However, I’m not a primary screen-reader user. I would be interested to hear the preferences of those who actually are.

  3. Jason, absolutely true with respect to off-screen content for tabs. Particularly vexing when the tabs are used to create a functional interface with form fields/links etc.

    Marco, thanks for stopping by and for leaving a comment. This is key:

    This would be especially tiresome on sites with extensive sub-menus.

    In this case, the menus aren’t that extensive or difficult to navigate. But, yes, you are correct, that setup would be optimal. That’s coming up in another article soon — we’ll walk through that scenario as well, and include ARIA for great compatability.

  4. George Hite says:

    I noticed that for option #2 and #3 you are using javascript to pull off your keying events or tabbing through…but if javascript is turned off you have the same problem as what you mention in your article.

    Is there an option for someone to go through the drop down (if they want to …referring to Marco’s annoyance) using CSS alone without having to rely on some other language (javascript) or plug-in?

    Thanks.

    1. I noticed that for option #2 and #3 you are using javascript to pull off your keying events or tabbing through…but if javascript is turned off you have the same problem as what you mention in your article.

      Yes, we use JavaScript. In option #2 with off-left positioning and JS off, you would have the same issue. Another case for not using off-left positioning. In option #3, with JS off you would only get the top level links and the sub-menus just wouldn’t appear.

      Is there an option for someone to go through the drop down (if they want to …referring to Marco’s annoyance) using CSS alone without having to rely on some other language (javascript) or plug-in?

      Hi George — there are significant problems with CSS only solutions — with CSS selectors you can only get at children, not parents so tabbing through links/menus backwards doesn’t provide you the ability to bring the entire sub-menu back on screen when you tab backwards onto a link, for example.

      Is there a particular concern you have with JavaScript off? If coded correctly, and you have all the submenu content on appropriate landing pages, you should be just fine. Not optimal, but fine.

  5. George Hite says:

    I forgot to mention that my css drop down menu works fine on IE8 and up, Firefox, Chrome, and Safari on Windows (don’t know how if it works on Mac because I don’t own or know anyone who owns one).

    I think a better solution would be one that works both in css (in case JavaScript is off) and JavaScript. The JavaScript version would override the CSS version since it makes for a better user experience.

    If technology was perfect a CSS version would be optimal because it would require less bandwidth and coding…at least in my opinion. But of course there is no such thing 🙁

  6. I think a better solution would be one that works both in css (in case JavaScript is off) and JavaScript. The JavaScript version would override the CSS version since it makes for a better user experience.

    That’s exactly what Option 2 does. With JavaScript on, you’ll get the optimized experience. Without JavaScript on, you don’t run into the issues that you have with a CSS only solution (like tabbing backwards through the navigation). Without JavaScript you have access to the top level elements and you get the sub-menus on the landing page for the section.

    The best of both worlds!

    1. George Hite says:

      It looks like my second post didn’t post… I talked about my own css drop down menu that, although not perfect allows one to go forward and backward without Javascript…

      I also described my issues with JavaScript…mostly dealing with the fact that some people at my office have it turned off.

      Not to repeat my second post if it is just stuck in cyber space somewhere before posting… I would like you to review my drop down CSS menu to see if it really is or is not accessible. IF you wouldn’t mind 🙂

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.