Best practice for semantic/accessible side menu
I'm planning new functionality for a site and before I start, I want to get the HTML structure right in my mind first. But as I plan this out, I find that I'm not totally sure whether what I'm doing is indeed best practice use of semantic elements and aria attributes.
I've attached the basic wireframe and my intended code structure, with the rationale underneath. I'm first examining the structure of the final HTML, rather than the script needed to handle the interactions. I'm very open to different viewpoints and feedback 🙂 Here are the previews and code:
I've attached the basic wireframe and my intended code structure, with the rationale underneath. I'm first examining the structure of the final HTML, rather than the script needed to handle the interactions. I'm very open to different viewpoints and feedback 🙂 Here are the previews and code:
13 Replies
This is a new menu for a news/blog summary page.
* I've gone with an <aside> element to contain the sidebar - it's connected to the articles, but still separate.
* The purpose of the categories is a filtering interface, so I'm using a <nav> to contain those links and popups.
* An unordered list holds buttons for each category because they control opening a popup.
* I've placed each popup as a sibling to the button primarily as I think that would be an easy way to control visibility using CSS based on the aria state of the buttons.
* The popup is just a div but with role="dialog"
* I used an h2 as the heading inside the popup - I don't want these headings to impact the overall document outline integrity but ensure the relevance in the context of the container. So I have an aria-labelledby on the popup that points to this h2 - I'm hazey about whether this is a good idea. Also, the title text here is essentially identical for all popups, instead of 'Featured Cybersecurity articles' because I thought it would be unnecessary repetition of the terms and also make the headings too long.
* There is another unordered list to hold the links to the articles, which are <a> as they will open the destination article.
* There is a button for 'See all articles' but I think this would depend on actual implementation because if the page does NOT reload, and the articles just filter in place dynamically then i'll keep it as a button. But if it reloads the same page with a URL parameter to filter the articles, then I'd change it to an anchor <a>
In terms of interactions, activating the category buttons toggles the aria-expanded attribute.
Responsivity to mobile:
I've only depicted the desktop view. My thought is to get a proper state of HTML and then consider how this could and should work on different screen sizes...
Thoughts re: design.
The western eye reads LtR TtB
So I would want any CTA to be on the LHS.
I'm unsure if I would want the navigation to be the first thing my eye is drawn to but then there are plenty of sites that do it so 🤷
Re: Use of Aside.
An aside is exactly as the name suggests, it's not the main thing but it's related to it.
So you could have an article and an aside within the article that has sort of relevant information but isn't required.
Example from the docs (
<article>
<p>
The Disney movie <cite>The Little Mermaid</cite> was first released to
theatres in 1989.
</p>
<aside>
<p>The movie earned $87 million during its initial release.</p>
</aside>
<p>More info about the movie…</p>
</article>
)
A Div is what is required here for styling purposes. You aren't conveying structure with the aside that the Nav wasn't already doing so
Re: dialogs. They are a complicated thing and unless you are intending on capturing user inputs and handling keyboard interactions among a plethora of other things it's better that you don't use that role imo.
When in doubt with aria, don't use it.
Re: placement of popup adjacent to their button, most JS based content will be mapped out and event listeners will collect what will be opening. The content being shown does not need to be next to the button at all (especially as the popup will be put in the same spot each time, there will just be a connecting background to identify the active category, easily done with css)
Typically re: form inputs you want to give them a name to collect their contents when the form is submitted. As screen readers and assistive technology is silly sometimes I'd also stick with adding a label element that is hidden visually but accessible to the reader.
Re: H2, do you have a H1 present on the page?
Sorry for the dump. Am on mobile so just vomiting out info rather than typing it outGood point on the aside.
If the popup opens because of user interaction, is it still proper that the popup element doesn’t have the role set? One reason I added is to ‘enclose’ the h2, at least from a document structure perspective.
If I was to use a document overview tool to list out the headings and check they make sense, ie no skipped headings levels and that they are summarising the page content logically, I don’t want the popups to muddy that overview. In the other hand I may be overthinking it considerably 😕
Great point on the label for the inputs. I didn’t know the assistive tech could have issues without it so I can definitely add that.
You can use anything to label it.
You could just hardcode it into an aria-label.
Use the h2 if it is semantically relevant as a heading and is preceded by a h1.
Re the role.
Would you say a hamburger menu is a dialog?
Here I've been going through a lot of Adrian's stuff recently thanks to Kevin's responsive table YT vid.
This explains why you are making your nav more complicated than it needs to be
https://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html
Adrian Roselli
Don’t Use ARIA Menu Roles for Site Nav
Once again, the advice is in the title of the post. But I will ramble anyway since you scrolled this far. First run with the advice, and then review some background on ARIA and how navigation and menu items are defined. This way you can tap out quickly when it…
I’ll go through that. Getting the right use of semantics and aria markup has been quite a learning curve as it doesn’t always seem obvious which to use and why 🙂
I also believe that all of the menu items would be tabbable to regardless if the menus were collapsed or not.
Probably be best to include a skip link to the content
Another good point 🙂
Html is much more complicated than people give it credit for imo.
Usually ppl scratch the surface and get into JS thinking they know enough. They then program a site that is completely unusable to a decent portion of the worlds population
Don't beat yourself up regarding it.
Nested menus are also gross.
What I'd do is have a look around for some live examples
Yeah, I used to started with js and css but now I find I want to get the right semantics to help guide, or narrow, what would be suitable interactions. I’ve found that I have ended up with better experiences that way, although this one has made be unsure whether the right elements are being used…
When I've taken a dive into a real menu I've lent heavily on Heydon and Stephanie
Smashing magazine article - Heydon Pickering (external link) https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/
W3C Authoring practices (external link) https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/
CSS only Dropdowns - Stephanie Eckles (external link)
https://moderncss.dev/css-only-accessible-dropdown-navigation-menu/
Smashing Magazine
Building Accessible Menu Systems — Smashing Magazine
There are lots of different types of menu on the web. Creating inclusive experiences is a question of using the right menu patterns in the right places, with the right markup and behavior.
Web Accessibility Initiative (WAI)
Example Disclosure Navigation Menu
Accessibility resources free online from the international standards organization: W3C Web Accessibility Initiative (WAI).
Modern CSS Solutions
CSS-Only Accessible Dropdown Navigation Menu | Modern CSS Solutions
This technique explores using: animation with CSS
transition and transform, using the :focus-within pseudo-class, CSS grid, and accessibility considerations for dropdown menus.All in all it's good to know and if you do know id count you above most other developers