Bdtjtk

I have a <nav> element with 2 levels. The top-level items are marked up with <button> tags and the child items with <a> tags, such as:

<nav role="navigation">

    <ul>

        <li>

            <button type="button">Category 1</button>



            <ul class="submenu">

                <li>

                    <a href="/cat1/subcat1">Subcategory 1</a>

                </li>

                <!-- ... other links -->

            </ul> <!-- /.submenu -->

        </li>

        <li>

            <button type="button">Category 2</button>



            <ul class="submenu">

                <li>

                    <a href="/cat2/subcat1">Subcategory 1</a>

                </li>

                <!-- ... other links -->

            </ul> <!-- /.submenu -->

        </li>

    </ul>

</nav>

The top-level items are intended to act as containers only and do not have pages of their own to link to.

How should I add keyboard accessibility to this markup?

Options I've thought about at the moment are:

Option 1

Open the menu when top-level items (<button> tags) are focused.

Keep the menu open as the user tabs through the child items.

Close the menu when the focus moves to another top-level item or the rest of the page.

Also, allow closing the menu via the Escape key and transfer focus.

Option 2

Use the focus semantics that a role="menu" would get, namely:

Enter, Space or Down arrow on the top-level item open the menu;

Down arrow on a child item moves focus to the next item;

Up arrow on a child item moves focus to the previous item;

Up arrow on the top-level item closes the menu, and;

Escape key while on a child item, closes the menu and transfers focus to the top-level item.

This would allow the Tab key to be reserved for moving to the next top-level item.

Personally, I prefer Option 2, but I do wonder if it blurs the lines between what's expected and what's shown.

Option 2 initially feels like the right keyboard semantics but that behavior should be reserved for "true" menus in the classic sense of the word. That is, menus such as "File, Edit, View..." that have immediate actions listed under them (such as File > Open or Edit > Preferences). Option 2 also means that your menu would have to be one tab stop and the user would use left/right arrows to move from "Category 1" to "Category 2". I don't think you want that.

For navigation "menus", they're not really menus in the classic sense. They're just a grouped list of links to navigate to other pages.

There's an excellent tutorial on menus on W3C - https://www.w3.org/WAI/tutorials/menus/. (There's a section on "application menus" in that tutorial that talk about the "classic" menus such as "file, edit, view", as mentioned above.)

I almost always recommend using buttons for immediate action things and links for navigating to another page, but with navigation menus, links are often used even if they only control the dropdown list of further menu items (which is usually a button's job). Whether you use buttons or links for your top level items is up to you. Personally, I would use links so that all the elements in the <nav> are links, but that's just personal preference.

In any event, whether you use a button or a link for the top level items, the element should have aria-expanded set to "false" initially. When the user selects the top level link, change aria-expanded to "true".

Here's the keyboard behavior I would expect:

• I should be able to tab across the top level items. Tab from "Category 1" to "Category 2". (The visual appearance of the top level items should have a "down triangle" or some icon that indicates there is something in that menu.) Do not open the submenu when a top level item receives focus. That makes it very difficult for keyboard users to get to the last top level item because they'd have to navigate through every submenu.


• As I tab across the top level items, I should be able to hit enter to expand the dropdown menu. The focus should not be moved to the first submenu item. It should remain on the top level item. Pressing tab should take me to the first submenu item. (If your DOM has the submenu items immediately after the top level items, you will get this tabbing behavior "for free". Your sample code is a good example.) I can then tab through all the submenu items.


• If I press esc while tabbing through the submenu, the submenu should dismiss and the focus should be moved to the top level item that opened the submenu (and aria-expanded should be set to "false" for the top level item).


• If I tab off the last submenu item, the submenu should close and the focus should go to the next top level item (and aria-expanded should be set to "false" for the top level item that opened the submenu).


• If I shift+tab off the first submenu item, the focus should naturally go to the top level item that opened the submenu. The submenu should still remain visible. If I shift+tab again, then the submenu should close and the focus should go to the previous top level item (and aria-expanded should be set to "false" for the top level item that opened the submenu).

It sounds a little complicated at first but is actually quite simple and elegant. The nice thing is that most of the tabbing behavior you'll get for free. You just have to implement enter to open the submenu, esc to close the submenu, and some onblur() handlers to close the submenus.

As a side note, you don't have to specify a role for native html elements that already have a default role assigned. For example

<nav role="navigation">

should just be

<nav>

and

<button type="button">Category 1</button>

should just be

<button>Category 1</button>

The html5 spec for <nav> and <button> shows you the default role and specifically says

(default - _do not set_)

(Also, your <nav> should also have an aria-label or aria-labelledby. This is mentioned in the "Label menus" section of the tutorial mentioned above.)