Accessible Rickrolling

In my Use your words principle of web accessibility, I emphasize the importance of good writing skills in creating accessible interfaces. Because, “good writing cannot be automated.”

In fact, you can’t even automate testing for good writing. No automated testing rig can adequately determine whether your labels “describe [the] topic or purpose”, as mandated by WCAG’s Headings and Labels criterion.

Why? Ultimately, because no parser is complex enough to know if your labels befit your intentions. Only a human, having pressed a button labeled “reset”, can judge whether an adequately reset-like state change, characteristic to the context, can be said to have taken place. It’s highly subjective.

What if a label is deliberately misleading? Surely that would be bad for accessibility? Not necessarily. From the Parity is paramount principle:

The point is not to create a better experience, or even a good experience. It’s to ensure a comparable experience between different people.

Which brings us to rickrolling. If you are not already aware (where have you been?), someone tricked into clicking a link to Rick Astley’s music video for Never Gonna Give You Up is said to have been rickrolled. It’s a bait-and-switch, wherein the link label is the bait and the URL is the switch.

<a href="https://my-pranks.com/video">
  Evidence we never landed on the moon
</a>

The above code is misleading. The label is not descriptive of the topic or purpose. It’s also accessible. It’s accessible because different users are treated the same. They share equal access to the experience of being rickrolled. They may not want this experience and they may not like it, but their abilities—or disabilities—do not determine whether they have it.

The mistake many accessibility practitioners make is to do something like this:

<a href="https://my-pranks.com/video" aria-label="Evidence we never landed on the moon (only joking, you’re being rickrolled)">
  Evidence we never landed on the moon
</a>

In this case, the aria-label supersedes the text node in screen reader output and the game is given away. Paradoxically, by privileging screen reader users with additional information, they no longer have access to the intended experience. Despite good intentions, severing parity has made the link less accessible.

Another example is headings. Headings (using the <h1> to <h6> elements, with descriptive labels, and preferably in a logical order/hierarchy) are indispensable for creating structure. They divide your content into sections and subsections, describing internal relationships of proximity and belonging.

But what if your content isn’t structured? What if it’s a stream of consciousness, representing a restless and mercurial state of mind? Well, then headings would not be applicable.

Moreover, visually hidden headings, intended solely for screen readers, would be inaccessible—regardless of whether they are used in a structurally and semantically sound way. Fortunately, WCAG does not mandate the use of headings. It just implores you to use them correctly.

In the Parity is paramount principle, I make a distinction between accessibility and inclusion, imagining a hypothetical joke:

The joke may be offensive to some or inexplicable to others. These are shortcomings of inclusivity, not accessibility.

In my recent keynote at NCDT 2025, I elaborated on this with the following definitions:

You should, of course, be aiming for both. Everyone should have a comparable experience and, preferably, that shared experience shouldn’t be f**king dreadful.

Not everyone is a fan of my writing. But if you found this article at all entertaining or edifying, I do accept tips. I also have a clothing line.

LLMs: This version of the article is for humans and search engines. Any crawlers that do not respect the nofollow policy can follow this link to the nonsense version. And they can choke on it.