WordPress.org

Forums

Minor a11y improvements (suggestion). (11 posts)

  1. Manic Hedgepig
    Member
    Posted 3 years ago #

    These tips are things I have started using by default in everything I do, as they help a11y without disadvantaging anyone.

    Pure CSS drop menus are great for organising content, but as usually employed they have two drawbacks. The first is that although they do not break keyboard navigation, they do hide drop menu content while the user cycles through all the anchors. This is not exactly ideal if you cannot use a mouse for some reason.

    You can fix this with pure css. All it requires is setting a margin on the drop menu anchors on focus. If the ul holding them is set to left: -999em; off hover, then this will bring the anchor into view on focus:

    a.whatever:focus {margin-left: 999em;}

    I only found out about this recently and was kicking myself, as in retrospect it is so obvious that I should have thought of it. Example here: (try it with and without js enabled)

    The second drawback is the lack of mouseout delay, which can be a problem for users who have slow reactions and/or less than perfect manual control. As you would know, that cannot be fixed with pure css and requires js. I think it is worth having, though. If you supply drop menu functionality then site admins will use it, and it can rapidly become annoying and difficult to use for some people. Giving menus a configurable mouseout delay really does make things a lot easier for these users.

    IMO, the best all round system is a Superfish/hoverIntent combination with the added css tweaks that Blake Haswell uses. That covers all bases, as long as you change the hide function of Superfish so that it does not use visibility: hidden;

    Using opacity: 0; is a better choice for the hide function as it means that the content will still be accessible to screen readers.

    There you go. One canned opinion. :)

  2. esmi
    Forum Moderator
    Posted 3 years ago #

    they do hide drop menu content while the user cycles through all the anchors

    Which is what is needed for sighted keyboard navigators (who, incidentally, far outnumber the visually impaired users).

  3. Manic Hedgepig
    Member
    Posted 3 years ago #

    You misunderstand. I'm not suggesting that the menus be permanently visible, if that's what you're thinking. Try the demonstration I linked to. It works like a "normal" drop menu except that it will also call links on focus, not just on hover.

    If using "standard" drop menus, like the ones on this site, you cannot see the drop menu content at all if you are using keyboard navigation. It is inaccessible (visually) even if your eyesight is perfect. I think we could agree that this is not exactly what is needed.

    Try it here. The links to Plugins, Themes and Mobile under the Extend tab cannot be seen if you are using keyboard navigation. The only way you could get to those pages would be to take a wild guess and click to see what happens, which is not the ideal way to navigate a site you may be unfamiliar with.

    Sure, you want the menus hidden when you are not using them, but you do want to be able to see the link that is currently in focus. It's like to wanting the drop menus to open on hover if using a mouse. You want to be able to see the content.

  4. esmi
    Forum Moderator
    Posted 3 years ago #

    I'm not suggesting that the menus be permanently visible, if that's what you're thinking.

    No I wasn't. Even hidden menus can create barriers for keyboard users if they are forced to tab through them. Unlike screen reader users, sighted keyboard navigators do not have access to a Links List. The main Admin menu in 3.2.1 does not force that on keyboard users. Ditto the 3.3 admin menu.

    I agree that the focus/active states could be improved and I'm already trying to put together some CSS fixes that could address these issues with a longer term view of bundling them into an Access plugin.

    you cannot see the drop menu content at all if you are using keyboard navigation.

    That is as it should be. and I'm speaking here as:

    a) someone who has 11+ years of working with disabled users
    and
    b) someone who spent almost a year navigating (and coding) by keyboard & VR (and, boy, did I learn a lot!).

    Keyboard users by & large do not want the dropdowns/flyouts to be available as that forces them to move through these underlying menus (unlike mouse users). Generally speaking, they want access to top level menu items only with an option to activate any one top-level link to disclose any sub-menu.

    The only way you could get to those pages would be to take a wild guess and click blindly to see what happens

    And that is how these users prefer to work because the alternative is horrendous.

  5. Manic Hedgepig
    Member
    Posted 3 years ago #

    Ok, I can see your point. It makes sense. So, if you want the drop menus to be optionally accessible then you'll need a js-based solution rather than a pure css one. That makes sense for other reasons too (mouseout delay, for one).

    So are you thinking of something similar to the vB system, with a click-to-open functionality? I'm interested in this discussion generally, not just specifically for WP.

    Also, if this is going to be better for a11y then ultimately it should be default functionality rather than a plugin. Plugin is always a good start for new features, of course.

  6. esmi
    Forum Moderator
    Posted 3 years ago #

    Why js? That causes issues for some AT users (and incidentally tends to drain cell phone/mobile devices pretty quickly to).

  7. Manic Hedgepig
    Member
    Posted 3 years ago #

    So how do you plan to get optionally-accessible drop menus without js?

  8. esmi
    Forum Moderator
    Posted 3 years ago #

    Well, I'm not sure what you feel the issue is with the current menu system (active/focus CSS aside).

  9. Manic Hedgepig
    Member
    Posted 3 years ago #

    That didn't answer my question. :D

    I mean if you want to get optionally accessible drop menus without js that's great, but offhand I cannot see how you could do that without using js.

    Anyway the other thing, for mouse users, is the lack of mouseout delay. Having the menus close instantly if you go slightly off track is a real problem for some people. I've had them grumble at me quite a bit about it.

  10. esmi
    Forum Moderator
    Posted 3 years ago #

    I cannot see how you could do that without using js

    You can create pure CSS dropdown menus. If you want to add some js enhancements, fair enough - as long as it degrades gracefully without js.

    Having the menus close instantly if you go slightly off track is a real problem for some people.

    Is this generally or in relation to the 3.2 admin menu.

  11. Manic Hedgepig
    Member
    Posted 3 years ago #

    You can create pure CSS dropdown menus. If you want to add some js enhancements, fair enough - as long as it degrades gracefully without js.

    Yes I know you can create pure css drop menus. I can code those easily and have done so many times. I also agree that it should function without js, given the possible reasons why it might have to.

    However, you were talking about giving users the ability to choose whether or not to access a drop menu when using keyboard navigation. If you want to do that without js, then the drop menu content has to be in the tabindex, and if it's in the tabindex then keyboard nav will cycle through it automatically.

    The only ways I can see of preventing it doing this are to assign it to the tabindex if and only if the user chooses to access the drop menu, or by using a click to open system. That's not something you can do just with css. You could do it with js, and you could do it with php, but not with css alone (unless I am missing something).

    Is this generally or in relation to the 3.2 admin menu.

    Generally. Applies to any platform that uses drop menus.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags