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:

The main page content.
A tantalising snippet from another page.

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:

The main page content.
A tantalising snippet from another page.

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.

Accessibility in your inbox

I send an accessibility-centric newsletter on the last day of every month, containing:

  • A roundup of the articles I’ve posted
  • A hot pick from my archives
  • Some interesting posts from around the web

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. Images as the first thing in a button or link

    If the text of an interactive element like a button or link is preceded with an accessible image, we’ve probably got an accessibility problem.

  2. Alt text for CSS generated content

    There’s an interesting feature in Safari 17.4 that allows content added with CSS to have ‘alt’ text. I’m not sure how I feel about this.