0

How should focus ideally behave in a modal navigation drawer (much like the one from Material Design)? The modal would appear when I webpage is viewed on a small screen, be opened using a hamburger button, disable the other page content using a scrim and contain a list of links.

I can think of four subquestions.

First, where should focus go after I open the drawer (in my case using hamburger button)? Should it stay on the button? Or should it go to the first link in the navigation? (To me, the first option seems more intuitive.)

Second, what keys should users use to move between the links? The options are [Tab] and arrow keys. (To me, [Tab] seems like the obvious choice, but I have noticed that Google Sites uses arrow keys and moves focus out of the modal with [Tab].)

Third, what should happen when focus moves forward from the final navigation link? Should it go back to where it was in the other page content before the drawer was opened and close the modal? Or should it cycle back to the drawer’s first link? Or to the hamburger button? (To me, the first and the last options seem like good choices.)

Fourth, what should happen when focus moves back from the first navigation link? Should it go back to where it was in the other page content before the drawer was opened and close the modal? Or should it cycle to the drawer’s last link? Or to the hamburger button? (Again, the first and the last options seem like good choices.)

The most closely related guidelines I can find is WCAG 2.0:

2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

From what I can see, these guidelines are in line with everything that I have thought of above. What do you suggest that I do? Do you have some other resources for me to read?

4
  • Sadly no comments / answers. I was searching for almost the same thing and found this question. Did you happen to get answers from other sources? I was recently developing my own modal window for a closed-source project for a customer and agreed to implement a keyboard trap for modal confirmations. Focus on the modal title, so that navigation starts with it when modal confirmation dialog is opened. Then a trap, so that user can not tab outside before (s)he answers. And yes, Tab keys for tabbing. So - keyboard trap is actually needed for best result here, I believe. Commented May 11, 2020 at 13:58
  • @nettutvikler No answers from other sources. I decided not to use a modal in the end. But I believe a keyboard trap is the way to go. The final options to point 3 and 4 seems the best to me today. Also, let the user close the modal with [Esc].
    – Fredrik P
    Commented May 14, 2020 at 9:40
  • 1
    @nettutvikler Also, look at the example modal from W3C.
    – Fredrik P
    Commented May 14, 2020 at 13:14
  • Thanks. Yes, I've looked at the W3C examples and got some nice ideas I've used. Maybe native dialog will solve some issues in the future but it looks like the styling of native components can sometimes bee to "locked" and therefore we have to re-invent the wheel each time a new design arrives. That is potentially causing a lot of accessibility issues and additional work... Commented May 14, 2020 at 23:13

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.