Skip to main content

Years in, the accessibility learning curve continues

Posted in Accessibility and Development

I’ve cared about accessibility for as long as I’ve been working in the web and, even after all these years, I still enjoy learning new things. The more I design, build and test, the more edge-cases I come across; recently, I realised that <aside> elements are higher-level than I thought. Let me explain.

MDN web docs says this about the <aside> element:

The HTML <aside> element represents a portion of a document whose content is only indirectly related to the document’s main content.

I took this to mean "wherever there’s some content that’s indirectly related to the document’s content, use an <aside>. I would have written something like this:

<body>
<main>
The main page content.
<aside>
A tantalising snippet from another page.
</aside>
</main>
</body>

I was wrong. You see, I do most of my screen reader testing in VoiceOver, which seems to be more forgiving in this area than others must be, so this has never presented an issue.

The problem

<aside>s get an implicit ARIA landmark role of complementary and it turns out you shouldn’t use role="complementary" inside any other landmarks.

It makes sense when you think about it – it’s content that’s complementary to the document itself, not a part of the document. Using <main> as an example, once you’ve used the <main> landmark, you’ve told the browser that that’s the primary page content, so any <aside>s in there would be related to that, not the document itself.

What’s more, Deque’s documentation on the use of <aside> explains that misuse can cause problems for some screen readers:

Screen reader users have the option to skip over complementary content when it appears at the top level of the accessibility API. Embedding an <aside> element in another landmark may disable screen reader functionality allowing users to navigate through complementary content

I want people navigating my sites with screen readers to be fully empowered to skip (or navigate directly to, if they prefer) my complementary content, just as a sighted user can identify an advert, for example, and ignore it.

The fix

So here’s how we’d alter the earlier example:

<body>
<main>
The main page content.
</main>
<aside>
A tantalising snippet from another page.
</aside>
</body>

Basically, as soon as you’ve defined any landmark on the page, you’ve ruled out using an <aside> in there – <aside>s have to be children of the <body> element (with as many <div>s in between as you like) or you’re making life difficult for screen reader users.

Here’s a quick run-down of the sectioning elements that you shouldn’t use an <aside> inside of:

  • <article>
  • <footer>
  • <header>
  • <main>
  • <nav>
  • <section>

It’s worth mentioning that it is safe to use <articles>s, <footer>s, <header>s, <nav>s, and <section>s (not <main> – only one of those is allowed per page) inside an <aside>.

Avoiding this kind of thing in future

Just like browsers, there are issues that show up in some screen readers and not others. Testing across various operating systems with different screen readers is always best, but before we get there we should take advantage of other tools at our disposal.

Ensuring our markup passes validation is a great the first step, and running a test with a browser tool like axe flags pretty much every other issue I’ve encountered. Having run some tests like this, you can be confident that your screen reader testing will be as snag-free as possible.

Subscribe

If you enjoyed reading this and want a monthly roundup of my articles delivered to your inbox, just enter your email below.

I don’t collect any data on when, where or if people open the emails I send them. Your email will only be used to send you newsletters and will never be passed on. You can unsubscribe at any time.

More posts

Here are a couple more posts for you to enjoy. If that’s not enough, have a look at the full list.

  1. Mac event 2021

    Apple had their final event of the year last night and it was especially exciting as I’m in the market for a new Mac. Here are my thoughts.

  2. Face ID on the Mac won’t happen

    With an October Mac event looming, I got to thinking about Face ID on the Mac; I don’t think it’ll be added now, and might not ever be.