If you’re at all involved in web development and concerned with
accessibility, there’s a good chance you saw one or more articles
recently debating the idea of adding a native way to visually hide
elements in the DOM without
removing them from the accessibility tree. It kicked off when TPGi
published a
breakdown of the .visually-hidden class
and my friend
Ben published an article
suggesting that accessibility on the web might benefit from having a
native, spec’d mechanism to do this. Then a couple of other
accessibility experts published responses where they argued against
adding a spec for visually hiding elements.
I have my own thoughts about this and I plan to write about them, but in this post I thought I’d write about some changes I’ve made to my blog as a result of this debate.
Visible Labels
I recently converted all of my
Nunjucks templates
to WebC. As I was going
through the templates, I was surprised to find a number of them that
used aria-label. Usually when I add
aria-label or .visually-hidden to an element
on a site, I find myself asking whether or not everyone would benefit
from reading this text. If it’s helpful to someone using assistive
technology, maybe it would also be helpful to someone who isn’t and I
should just show it.
I left them in-place because I was trying not to get side-tracked by
redesigning my site while I was just trying to move template engines,
but reading through the arguments opposing a native
.visually-hidden I became motivated enough to revisit my
use of invisible accessible names.
Unlabeled Icons
I had a couple of icons in my footer that had no visible labels: the
link to my RSS feed and my CodePen profile. Both used
aria-label to provide accessible names for the links.
Generally speaking, I oppose unlabeled icons because there’s no
guarantee that a person both recognizes what the icon is meant to be
and correctly infers its purpose in the interface. And it’s very hard
to search for an icon. A labeled icon, on the other hand, is more
likely to be understood correctly, and failing that, the label can
always be used as a search term.
Nonetheless, I opted for unlabeled icons because I thought they looked nice. I figured that social links like this are common enough in footers—at least I see them pretty regularly—and the stakes were pretty low. The worst outcome is that someone who doesn’t recognize the RSS logo, clicks it, and gets a face full of XML.
But in light of the debate over enshrining
.visually-hidden in a spec, I was scrutinizing this
decision more closely. I decided that, although it was probably
ok to have these icon-only links down there, I didn’t
need them to be unlabeled. There were few enough links, and I
had enough space in the footer, that I could simply stack them
vertically in a bulleted list and make the labels visible next to the
icons.
Post Metadata
The other place I was a bit surprised to discover some use of
aria-label on my site was in the metadata for blog posts:
the published date and the list of tags. I suppose I thought that a
person looking at the page layout could infer the meaning of these
pieces of text, but that their location in the DOM was insufficient
for a person relying on the accessibility tree, so I put accessible
names in the markup.
I suppose a person might see a date at the beginning of a blog post and assume that it’s the publication date, but why make them guess? So I collected the metadata for each post into a description list so that there would be clear labels for everyone1, not just in the accessibility tree.
Headings
I have to confess here that I was doing a bad thing on my homepage.
There was no <h1>. I could have fixed the
document outline without changing the design of the home page simply
by adding a .visually-hidden heading. I surveyed a number
of personal sites belonging to accessibility experts and a couple of
them use this technique. But as with the previous examples, I figured
if it’s useful for someone using a screenreader to know they’re
looking at my “Latest Posts,” maybe it’s useful for someone looking at
the page, too. So a visible <h1> it is.
I confess that of all the changes I made, I like this one the least,
aesthetically. I liked the simplicity of the home page with no visible
heading. But it’s fine and I have a hard time adding the
.visually-hidden utility to my CSS just for the
home page.
Visible Skip Link
Perhaps the most unusual change I made to the design was making the skip link visible in the header. Scott O’Hara suggests that skip links are a workaround for a missing browser feature: the ability to navigate a page using landmark regions. I’d never thought of it like that, but as someone who prefers to keep his hands on the homerow of his keyboard as much as possible, I would certainly appreciate some navigation shortcuts like this in my browser. That got me thinking that maybe the skip link isn’t just for people relying on assistive technology.
Especially given the ludicrous size of the headings on my blog
posts2, I thought that maybe some folks might like a quick way to just jump
right past the title and get to the text of the post. If nothing else,
I had plenty of room in my spartan header that I could just remove the
.visually-hidden styles from the skip link and it would
fit right in to the header. It was easy to add it, and I have trouble
imagining that it’s doing any harm.
The Lone Instance of Hidden Text
There is one extant use of aria-label left on the site:
the illustration of me that acts as a link to the homepage. It has an
accessible name of “Home” provided by aria-label on the
anchor element. I can’t really rationalize this decision, I just liked
this element of the design as-is and chose not to change it.
This is Not Advice
I’m not writing this to convince anyone they should eliminate visually hidden text from their site. I did this work because I wanted to see how far I could push such an exercise just for my own edification; although I do think my site is better for it (especially the metadata on blog posts).
Mostly I just wanted to step back from the question of “do we need a
native mechanism for visually hiding elements” to share how the mere
existence of the debate was educational for me. I appreciated how the
debate provoked me to take a closer look at some of my own
assumptions. Even though I was already in the habit of questioning
decisions about hiding text, I sometimes reached for
aria-label because others had done so, rather than asking
myself whether it was really appropriate for my context.