Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Revisit accessibility of main nav menu #137

@terrill

Description

@terrill

The main "Dawgdrops" navigation menu was build with accessibility in mind, but accessibility methods related to navigation menus have evolved since then. The current menu needs the following changes, which I've grouped into two phases:

Phase 1
The following changes don't require any changes to HTML structure of the menu; therefore should be fairly easy to make I think.

  • Remove role="application" from div.dawgdrops-inner
  • Remove aria-haspopup="true" from each top-level menu item (<a>)
  • Remove role="group" and aria-expanded from the <ul> that contains each submenu
  • Currently, when a top-level menu item has keyboard focus, the corresponding submenu can be opened by pressing either Enter or down arrow. Remove support for down arrow for this purpose. If no submenu is open, users should be able to use the down arrow for its default browser function (which for most browsers is scrolling the page down within the viewport).
  • If a user presses the Escape key when focus is anywhere within the <nav>, all open submenus should close, regardless of whether they were opened using the keyboard or mouse. (Currently, if a submenu was opened with a mouse, it's impossible to close it with the keyboard).
  • If a user opens a submenu by hovering with the mouse, all previously open submenus should close, even those that were opened using the keyboard.
  • If a user opens a submenu by pressing the Enter key on a top-level submenu, all previously open submenus should close, even those that were opened using the mouse.
  • When a submenu opens, the aria-expanded attribute on the top-level menu item should change to "true". Conversely, when the submenu closes, the aria-expanded attribute should change to "false". This change should occur regardless of whether the submenu was opened/closed with keyboard or mouse (currently the attribute value only changes on keyboard events).

Phase 2
Currently, the top-level menu item is serving two roles. It serves the role of a link (<a>) that leads to a new page, but also as a button that triggers the submenu. This isn't allowed in HTML, and there are only two ways to solve it:

  1. Change the top-level links to <button> elements, so they serve the button role, but no longer link to other pages, or
  2. Add a <button>, adjacent to the link. There's already a visual indicator to the right of each link, so this could be accomplished with little or no change to the visual design. That visual indicator just needs to be a <button>.

I've been told in the past that option 1 is not an option: Those top-level links are not expendable. If that's still true, option 2 would be the one to implement. The following additional steps assume there is both a link and a button for each top-level menu item:

  • Move the aria-expanded and aria-controls attributes from the link to the button.
  • Add aria-labelledby to the button, with a value that matches the id of the link (e.g., aria-labelledby="academics").
  • Currently if the top-level menu item (the link) has focus, pressing Enter triggers the submenu, whereas pressing Space follows the link. Remove the Enter key event listener, so Enter and Space both follow the link.
  • Add keydown event listeners on the button, so pressing Enter or space when the button has focus both trigger the submenu.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions