On Links and Accessibility

Published on Mar 6, 2014 (updated Feb 5, 2024), filed under development, accessibility (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

Hyperlinks and the underlying ubiquitous <a> elements are what make the Web. Just a few weeks back, Christian Heilmann wrote a little about why and how links are important, which I shared and responded to with a few more thoughts on links in hypertext.

But, there’s also an accessibility side to links. At least a perceived one, as, so I intend to show, bare <a> elements pointing to tangible resources using plain language with adequate information scent are enough.

Accessibility questions come up, for example, related to opening links in new windows and whether users of assistive technology need to be notified (similar to how some prefer to notify about “external” link targets). As happened also a few weeks back at WebAIM. Should users be notified about links that open in new windows? I like to use this specific question to look at links from a general accessibility point of view.

First, it’s important to understand that “if a non-disabled user has the same issue, it’s not an accessibility problem” (in a sense of locking out users). In our case, we can see that the notification problem is actually not one of accessibility.

Following another school of thought is the idea of “[if] a browser or adaptive technology can or should handle an accessibility issue, I won’t,” or we shouldn’t, which Joe Clark promoted in 2007. That idea makes our question, the notification question, a tool one.

Then, running through how accessibility affects links, the Web seems to have matured enough that we can say that

1. links should generally open in the same window (unless they invoke a different application), because it’s the user who can and should control how links are handled (like opening a link in a new window if so desired), and

2. links do not need any particular highlighting (unless, again, invoking different applications as for email or document links, which can be addressed also through appropriate link wording as in e.g. <a>jd@example.com</a> or <a>example report (PDF)</a>).

Now, finally and to work with another principle for good measure, it usually pays off to keep it simple. That means, a plain simple a@href—the bare anchor element from the beginning—that is styled so as to be recognizable as a link and indicates when it has been visited should be enough in 99% of all cases.

Tying this all together, and as I said in my response to the WebAIM question, use simple links, skip the extras, and don’t worry about them, the links. That’s my view, on links and accessibility.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)