On Links and Accessibility
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
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
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>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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. 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!
Maybe of interest to you, too:
- Next: The 6 Most Useful Books I’ve Ever Read
- Previous: CSS: When to Use Generated Content
- More under Web Development, or from 2014
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.