Here’s the part of Chris’s response with which I identified most:
I plan on writing a lot more about that experience, but right now I want to respond specifically to the question of when to use an anchor element.
The reader says that he
generally used the to represent an element as
a tag liberally
In brief, that’s the safest choice. But the natural inclination of a developer (ideally) is to dig as deep as possible and make the most informed choice. After all, their the ones who have to support it when things get wonky.
If you decide on something other than an anchor though, just make sure the element you choose is accessible to keyboards and screen readers. Easy. Done.
Of course, it can be a lot more complicated than that. Anchor elements are natively focusable and screen readers provide functionality for navigating a page by its anchors. This allows to users to quickly scan the page via their keyboard. Visual users often (and understandably) take for granted their ability to visually scan a page since it’s a natural response and not specific to viewing a webpage. But, substituting a different element can require a lot more effort in facilitating a equal experience to non-visual users.
tabindex with a value of
0 on a non-natively focusable element will allow for the element to be navigated via the tab key, and in the order of the natural document flow. But the catch is that a screen reader will not include the element in its anchor shortcut feature. This may not be necessary if the the element’s purpose would not make sense outside of its surrounding context, like a tooltip, for example.
More importantly though, the screen reader will not speak the element as a link. Visual users employ visual clues to interpret actionable elements in a page. Screen readers rely on semantics. While a visual user can instantly recognize a button by its design, a screen reader can do so only if a
button element is used.
Also, it’s good to understand that
title attributes are not necessarily spoken when a screen reader user is focused on an element that contains one. The popular screen reader JAWS provides this as an op-in preference. So using a
span as an actionable element will need both a
title attribute and screen-reader-only text (off-screen) to communicate to the user the purpose of the element.
Regarding ARIA, support is getting better, but it’s still pretty spotty. In fact, I’ve had to remove ARIA attributes at times because of screen reader conflicts. It can also change how the user’s screen reader interacts with a page (Form and Application modes). This can be disorienting to a user who has yet to master the full feature set of their screen reader. But after reading Dave’s comment below, I figured I should give the
link role a try. I use the
role when it’s useful, but the
link value is one I’ve never considered.
I used the following markup for my quick test:
<span id="link" role="link" tabindex="0">Test Link</span>
Surprisingly, JAWS 12 with IE8 spoke the element as a link. I was also able to navigate to it using the
u key shortcut (navigates unvisited links). The
v key did not register it as a visited link even though it had been clicked. That makes sense since there’s no
href. Good to know.
I’ve put up a page of various attempts to mimic links. Not exhaustive, but should be helpful in drawing general conclusions. I’ll add to it as I get more examples and time.