Building an Accessible Menubar Component Using React

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

The Submenu

The previous example is great for a single collection of links, but what if we replaced one of them with a dropdown that revealed a secondary set of navigation links?

Loading...

For this, we're going to need to create a second compound component — the

. It is composed of three functional components:

• The
  Loading...
  will hold shared logic and component state
• The
  Loading...
  will allow the user to expand the menu
• The
  Loading...
  will display the expanded menu items

The

keeps track of menu items within the . In turn, let's create a to keep track of menu items nested within a .

Loading...

Let's start by defining the

component. It'll share some similar behaviors and functionality to the . Alongside the index tracking, it also needs to know if its menu has expanded. We could declare another state variable with . Instead, it makes more sense to merge the logic into a reducer function.

The purpose of the

parent component is to hold the compound component state. It is also responsible for distributing shared logic to its sub-components. We assign the logic to a memoized object, after which that object is then passed to the value attribute of a .

Loading...

Now, let's define the helper methods for navigating the submenu's menu items. These are almost identical to the

helpers. The key difference is they dispatch reducer actions instead of updating the component state directly.

Loading...

Some functional requirements need the subcomponents to have knowledge of their sibling. We can achieve this by defining ids and references for each subcomponent in the

. Note that we store the within a reference object. This is to prevent the function from regenerating the id on every render. Each subcomponent can now retrieve the values from the hook.

Loading...

Let's now manage focus within the

. We'll start by adding another side effect. This one will focus the first child of the current index if the tracked indexes do not match. Whenever we update the current index, we focus the first child of the new current node.

Loading...

Submenus do not follow the roving tab index pattern. Instead, the tab index of each menu item within a submenu will always be

. This requires a small change to the component. If a exists, we can assume the is inside a and apply to its tab index.

Loading...

Trigger

With the

defined, let's create the component. We'll start by retrieving the and from the . Since a button's default type is , it's usually a good idea to override it to .

Finally, the

should only ever be a child of the . Like before, let's throw an error if we use it outside of a .

Loading...

Next, let's add the appropriate

attributes. will inform assistive technology that the button controls a submenu. To go one step further, we can also add the attribute. This informs the screen reader of the exact submenu controlled by the .

Let's also retrieve the

and the state from the . We'll assign the to . Then, all that's left is to assign the state to the attribute. Assistive technology is now aware of the menu button controls, and whether they are open or closed.

Loading...

Now, let's add keyboard support to the

. The will be a sibling of the Menubar menu items. That means it should perform the same events as the Menubar links. It also requires some additional functionality. Alongside the menu item behavior, the Trigger should:

• Loading...
  : Open the submenu and focus the last item
• Loading...
  : Opens the submenu and focus the first item
• Loading...
  ,
  Loading...
  : Open the submenu and focus to the first item

To do this, we'll retrieve some methods from the

and assign them to the relevant . Note that we only want to execute the method on unique events.

Doing so allows all other events to bubble up to the

. This is what prevents us from having to duplicate the menu item's events.

Loading...

Let's say a submenu is open when the user presses the

or key. The submenu should close and focus the previous or next menu item. If the root menu item is also a submenu, it should expand the menu but keep focus on the trigger.

The

achieves this by checking to see if the event originated from a submenu menu item. This ensures that the menu does not expand when other methods focus the trigger.

Loading...

List

Now that we have a

, all we need to do is create a submenu . Like the , we'll throw an error if the component is not used within a .

Let's also define some attributes. First, we'll apply the

and retrieve the from the . We'll retrieve from the context and assign it to the attribute. This will hide the List from the accessibility tree if the menu is not expanded.

Next, let's label the menu by assigning the

to the attribute. Finally, we'll supply the menu's direction to assistive technology with the attribute.

Loading...

Now let's add some

events specific to the component. We'll retrieve the appropriate helpers from the . Again, we only want to stop propagation on events that we do not want to bubble up to the 's event.

Loading...

The

component will work within a for the most part. We'll need to make a couple of changes to ensure that both the and can make use of the component.

The first change is to ensure that the correct

receives the node. We can assert that a submenu is an ancestor element if the can retrieve a . If it returns a false value, then the must belong to the Menubar.

Let's update the error to check for the

. The error should only throw if both contexts do not exist. A can now be a child of either a or a .

Loading...

There is one final change that we need to make to the

component. Let's revisit the structure of the .

The

currently clones its prop and appends extra props. In the example below, we can see that 's child is the component. The returns a context provider as its parent element. The provider returns nothing from render, and so the props are not attached to any DOM node.

Loading...

Instead, we would like to append the

's onto the submenu . To do so, the component will need to check its 's type.

If the type is a node, then we clone it and append the props. If the type is a function, then we instead provide the props as an argument in the function signature.

This allows us the flexibility of choosing which element should receive the props and additionally retains the convenience of appending the props onto the child by default.

Loading...

That leaves us with this flexible React markup:

Loading...

...which compiles into this beautiful, accessible HTML:

Loading...

Now, all that's left is to add extra logic for mouse pointer events, nested submenus, and a full suite of unit tests!

Unfortunately, we'll consider these features out of scope for this article and they would warrant a follow-up post to cover. I've included all the extra logic and the unit tests in the Code Sandbox demo at the top of the page.

Special thanks to Jenna Smith for her invaluable contributions to the initial API design.