When HTML5 was the new kid in town, multi-sidebar blogs were also very popular. And the <aside> element seemed like the right choice for sidebars - but is it?
Let's learn a bit more about <aside>!
In terms of assistive technology, an <aside> is announced with the implicit role of "complementary".
In terms of semantics, an <aside> cannot live within <main>.
For example - it's not going to be the right choice for ad content that lives within a <main>'s <article>.
By actual definition per MDN:
"The HTML <aside> element represents a portion of a document whose content is only indirectly related to the document's main content."
So what type of content can live there?
Example things <aside> can be used for:
- colophon/bio information
- related resources
- lists of things that are extra bonus content
So it can be a "sidebar" as long as it's outside of <main>.
For multiples - add aria-label or aria-labelledby to help users of assistive tech.
An <aside> should not be used for:
- extra navigation - use <nav> with an aria-label identifying it such as "secondary"
- pull quotes - use <blockquote>
- imagery/graphs - consider <figure>
- meta info important to the content - consider <footer>
A note that whether or not <aside> can be within <main> seems to be a bit contested.
I added that point because it's flagged as a landmark error w/ @dequesystems aXe - so if anyone can clarify if there are exceptions, we can learn something new and use <aside> more effectively!
The <aside> is allowed a few additional ARIA roles.
So by default, it's not allowed within <main> due to "complementary" conflicting with the "main" landmark role, but you may nest it by using a role of "region" or "note".
If an interaction relies on a mouse-initiated action, it needs to be keyboard accessible too.
This means it may need to respond to Space and/or Enter as a trigger (hint: you get that for free with <button>).
If it opens something, it may need to close with Escape.
If it's scrollable, it needs to respond to Up/Down arrow keys.
If it's a group of related options (like autocomplete or tabs), it may need to respond to Up/Down or Left/Right arrow keys (search phrase: roving tabindex).
If it opens a dialog/modal, it needs to prevent tab access with elements outside of that experience (search phrases: "trapping focus" and "inert").
If it's interactive *at all* it needs to be able to gain keyboard focus, and that focus needs to have a visible style.