Jens Oliver Meiert

Get 15% off on select books on Gumroad—use discount code “testdrive”.

On Links and Accessibility

Post from March 6, 2014 (↻ June 5, 2021), filed under .

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

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!

Read More

Maybe this is interesting to you, too:

Looking for a way to comment? Comments have been disabled, unfortunately.

Cover: The Web Development Glossary.

Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.

Stay up-to-date? Learn about new posts by feed or on Twitter.

Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2014 → On Links and Accessibility

Last update: June 5, 2021

Professional frontend developers produce valid HTML and CSS.