Accessible Navigation from Scratch

Talk by Adam Berkowitz / View Slides

No matter how users get to your sites, they deserve an inclusive, accessible experience. A main navigation component built with accessibility in mind goes a long way towards this goal. Fortunately, WordPress leaves the implementation of accessibility best practices up to theme and plugin developers. This means that by carefully thinking about how to build a menu from ”the ground up”, we can help all of our users use our sites better.

This presentation will demonstrate:

  • The basics of menu accessibility
  • How a custom WordPress Walker class can be used to create accessible markup
  • How to write flexible and extensible CSS to ensure that the menus are usable even without javascript
  • How to implement javascript that enhances the user’s experience

Questions on “Accessible Navigation from Scratch

    1. Well I’d hate to think that making a mega-menu is suicidal! I think that with most interfaces, we can look for accessible solutions. In this case, I would suggest a developer ask some critical questions:
      – Can a visitor operate the menu with a keyboard?
      – Can a visitor who uses a screen-reader get valid, useful, and equitable information from the menu?
      – Does the markup support appropriate ARIA attributes?
      – Does the menu conform to WCAG expectations?
      You could probably think of many more questions as well.

      But, I think there’s another larger question here especially if we’re building from scratch and not remediating a site. Who is the audience for this interface and why do we think they want it? That is – are we adding something because WE think it’s interesting? Are we adding it because some “higher ups” want it? Or is this piece of interface something that will actually help visitors? Sometimes, the answers to those questions may conflict. Other times they will overlap.

      In any event, I think that it’s often useful to examine areas where we can step outside ourselves and be imaginative. Ask yourself – “What would it look like if….?” and go from there.

      I hope this helps!

    1. Sadly I don’t have very good information to give you on this question. It is likely something I should investigate more thoroughly.

  1. Menus seem a web feature that hasn’t gone away over time. With SKIP NAV and one page sites becoming more prevalent, do you see them being phased out for simple, more accessible experienes?

    1. In short – no. I don’t foresee menus going away any time soon. That being said, there are two things here. One is that we should distinguish between sites which are literally one page and sites which are essentially single page applications. In the case of a site which is like a brochure site or landing site, a navigation component may not be necessary whatsoever. Or, it may just be a collection of anchor tags. In the other case, people need some way of getting forward and back, managing information, organizing their browsing, knowing what to expect, etc…

      The thing about a menu is that it’s not just an interface. It’s a graphical or structural representation of what the site authors believe is important. I don’t think their desire to demonstrate that is going away any time soon.

      I hope this helps!

  2. This is something that I’ve thought a lot about since starting this project. Basically, I think – yes. It’s good to move in the direction of more accessible markup. I think that adding aria-labels to submenu toggles is a useful improvement which could be refined a bit. It also gives developers a clue to look into the markup more closely.

    Other ARIA attributes could easily be added as well (aria-owns is a good example). Others attributes I’m not sure about. For instance, how would WordPress core implement and mandate the aria-expanded property? It needs to be changed through javascript otherwise (to a screen-reader) it would always have one state. I think also that the core team would need to think carefully about how a change from links-as-buttons to just-buttons would impact users. They would also need to think about what happens if a developer chooses not to use the default menu.

    That being said, I believe it is absolutely up to developers to take the many functions, filters, and classes currently available in WordPress to create accessible menus. This flexibility is, I think, a strength rather than a weakness. Is there room to grow? Yes. But perhaps what the core documentation should emphasize is something like – “this is how you use the nav_menu_link_attributes filter to create a more accessible menu”.

    I hope this answers the question! Feel free to be in touch if you like.

    Adam