On Links and Accessibility
Post from March 6, 2014 (↻ September 11, 2017), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: 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, very important is the idea of “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 “ 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 to be recognizable as a link and indicates when it has been visited should really 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 the Author
Jens Oliver Meiert is a tech lead and author (sum.cumo, W3C, O’Reilly). He loves to try things, particularly in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.