Should the HTML5 dialog tag be used for a toggleable responsive navigation menu?
It is common practice to have the primary website navigation always visible on larger devices (desktop and tablet) and shown/hidden with a toggle button ("hamburger menu") on smaller devices (mobile).
Is it proper to use the HTML5
dialog element for this type of responsive navigation?
Dialog Pros
1. dialog elements include a native keyboard trap. When a dialog is open, the tab index is isolated to the contents of the dialog, greatly improving the keyboard navigation experience.
2. dialog elements include native functionality to close model with the escape button.
3. dialog elements include native functionality to restore focus to the previously focused element when the modal is closed.
4. dialog elements include native functionality for a backdrop behind the modal.
5. dialog elements convey the intention of element to the browser allowing the browser to potentially render an element in the best possible way for the device. For example, select elements are rendered different on desktop browser than mobile browsers.
Dialog Cons
1. There could be SEO implications to placing the primary navigation in a dialog element. In an effort to circumvent possible consequences, the dialog element includes the open attribute.
2. The dialog element is technically never opened on larger devices. Instead, the dialog element is set to display: block. If the dialog is opened (dialog.show()) when the browser width increases, it causes the focus to change. The display:block; hack, circumvents the issue. This an atypical implementation could cause issues on some devices.
Example
https://codepen.io/jasonlav/pen/LYKOYEm8 Replies
I think popover is more appropriate than a dialog, though browser support for popover isn't here yet.
In general, do you want keyboard trapping on a navigation? I'm not so sure 🤷. I guess it depends on the nav design and everything else, but most examples don't block out everything.
The primary advantage of using the
dialog is the accessibility advantages (keyboard trap, esc to close, etc) on small screens that use the hamburger menu. On larger screens, where the full menu is always shown, these accessibility features are not implemented since the dialog is shown with display: block and technically never "opened."
If small screen hamburger menu does not cover the screen, then yes, the dialog element does not make sense and popover is a better solution. However, many websites have the hamburger menu cover the whole site (cnn.com, bbc.com, pbs.org, etc). CCN and BBC do not make the hamburger menu a keyboard trap; PBS does. I would argue that it should be a keyboard trap on all three of those websites since the small screen menu covers the entire screen when toggled otherwise users can potentially "tab" to links that they cannot even see!I think my one concern is that, when a dialog is closed, the content in it, I believe is hidden... this would require testing, but I think all screen readers have a way to skip directly to the navigation, and if it's inside a dialog, I'd be worried that it wouldn't be able to get to it. Definitely worth testing though.
its not hidden
its effectively unrendered at all, as if it didnt exist
like how the <template> tag works
the content is only rendered when the dialog is open, or when forced to render in some broken state by forcing a display property on it
but other than that, just pretend that it doesnt exist
and that the contents dont exist
I definitely agree with that concern (see Dialog Cons #2). On the large screen and small screen menu layout, I am able to tab through elements without any issue. Technically, on large screen layout, the dialog is closed, but forced to render via
display: block;. Therefore, I think that proves the rendering assessment by @ἔρως.
Using Safari and OSX voice over, I was able to test it as a screen reader. On the smaller screen layout, it works flawlessly. When the menu is opened, the screen ready notifies the user they are entering a dialog, which is probably helpful to the user. However, on the larger screen layout, it does say "dialog" when you enter the menu, which may be a little confusing. However, a dialog doesn't inherently mean it takes over the screen (e.g. dialog.show()), but probably is expected to be dismissible.
Optimally, I think the best user experience would be for the mobile version to use a dialog in this scenario and the desktop version to not use a dialog. However, that would involve manipulating the HTML so, definitely not an optimal solution technically. 🫤how about you just use a div with aria-expanded and an aria-label?
you can even style it so it is hidden when aria-expanded is false, and display of any type you wish with aria-expanded set to true
i think the voice software is supposed to announce thst it was expanded
aria-expanded should only be used on something that's focusable. It's for whatever controls something that opens/closes, not the thing that opens/closes itself. It's because the open/close of it is only announced when the item is focusedyes, i meant for the attribute to go to the E.g.: <ul> and not the <button>