Interesting question from reader Don Wilson:
I’m curious to know your opinion. When should we use anchor tags and when should we use something else?
I have generally used the `a` tag liberally whenever I wanted something to be clickable. I looked up the definition and it appears that I am using the `a` tag where it is not meant to be used. I looked through the GMail source and they are using `div` elements for most of their clickable things.
I think if you are going to put a
If you chose not to use anchor links for clickable functional elements, then:
- Use cursor: pointer; so users get the cursor that looks like you can click like they are used to.
- Use the tabindex attribute on the element so keyboard users can tab to it.
My only issue with using elements besides anchors or buttons is that they cannot be focused by the keyboard. The tabindex attribute isn’t all that great because you have to provide a value, and so you’d basically have to add a tabindex attribute to every single focusable element if you want to make the page act the way it should.
It’d be nice to have something like a “focusable” attribute, or have tabindex work without a specific value. This would prevent people doing stuff like
<a href="#">click me</a>or even
Sorry, didn’t read your full comment before I added my own. You already pointed it out, focusability.
Regarding: “you have to provide a value, and so you’d basically have to add a tabindex attribute to every single focusable element”
That is not quite how it works. tabindex=”0″ is equivalent to not specifying an attr/value pair, but it serves to bring an element into the tab index. Therefore, one does not need to alter tab order (which is very inadvisable anyway) in order to bring an element into the tab index.
@mark Great tip on the tabindex=”0″!
This discussion encourages me to consider more carefully where I use the anchor tag.
@Mark: There seems to be a bug in IE8 with
tabindex="0". Any element with this attribute is focused right away.
If you’re concerned with WCAG Accessibility standards you might want to consider replacing anchor tags with or tags.
tags with no href attribute or hrefs with hashes that don’t point to an element with that ‘id’ attribute on the page will get flagged by Accessibility Audit tools such as CodeSniffer.
Screen readers rely on a lot of standards and practices that have started to fall to the wayside along with XHTML and strict HTML.
Modern Browsers need very little in order to render a page correctly. I still cringe when I see people leaving out tags. I’d hate to see/hear what slack developer’s sites are like in accessibility mode or with a screen reader.
No way! Small world!
using DIVs or SPANs on non-link is great since you do not need to prevent default in the onclick.
How about the good ol’
<button>? Built-in hover (maybe just on Win), focus, and active statuses and no need for tab-index.
I use it only as form submit, almost exclusively.
I prefer to use anchors because you may bookmark dfferent states (for example, sitename#about, sitename#portfolio), while you can’t do that if you use div-s for that.
anchor tag is also more semantic and better recognizable in code than div.
I’m all against setting cursor to “pointer” for all clickable elements.
WebApp IMO is more an “app” and less a “website” therefore only actual links are supposed to have “pointer” and all other actions/buttons – “default”.
And it looks much cleaner too :-)
I prefer having “cursor: pointer;” on buttons and all clickable elements, just because it’s what I’m comfortable with. It makes me feel like it’s actually going to do something when you click it. :)
I always use anchor tags because some IE versions (big surprise!) does not support :hover on div elements
My normal ‘clickable-but-probably-fires-some-event-rather-than-navigation’ html looks like this usually:
<span class=”clickable” data-target-id=”someIdentifier”>Some descriptive text<span>
That said, I don’t write web-“sites” as much as applications, and lots of prototypes that need to be in a demo-able state on very short notice… perhaps if I was writing for more general consumption I would feel differently.
Agree with this.
I was going to write a comment about fall-back scenarios, but I just might end up by agreeing with Jesse.
Yep, if you are using
<a href="">, it must point to something real. Since JS can be turned off or blocked by a proxy/firewall/ad-blocker or fail due to some network error, user can open a link in new window or tab, copy address and do everything else what he or she can do with link. If you are using buttons, it’s good idea to use forms to make it work without JS too whenever it’s possible.
I do agree with the focusable argument. We can’t tabindex everything. You would need to re-index each time an element was added to the page. A focusable property would be great! For now, where I want the user to be able to tab, I will use anchor. If I don’t require the user to be able to tab there (because I’m implementing another way of using the keyboard to activate the element) then I will consider div’s etc.
But just a few days ago I thought about replacing all this stuff with buttons. This discussion just confirmed my plan.
I’m a proponent of using anchors for toggle events, and it seems the mid- & back-layer developers on my team prefer using form elements. I don’t understand this, at all, and haven’t received a satisfying response. From this post, it appears that anchors are still the most appropriate solution. Actually, a button might be a suitable option for the item in question, too. I’ll propose that tomorrow. It’s still not a form, anyway, and a lot more straightforward to style, plus more semantic than a form with a ton of hidden inputs.
I suggest a in-page-action <a> tag should be defined as a link (or anchor) in the current page. For example, set the HTML code:
Than we can see some friendly information in the status bar when mouse over the anchor, and we can also use the anchor styles at the same time.
In addition, I also use <button> tag quite open to for “clickable” meaning. But the styles is a problem.
<div> tag have no semantic meaning else. Does it appropriate?
I think its really all about the behaviour that follows… In a semantic point of view i would use anchor tags only if there is really a hyperrefference attached to it. So if there is a page reload happening or something similar i would totally go for it, otherwise you can still use a span element.
First of all Chris, thanks for responding to my question. This has been a cool experience to see your reply and for this great discussion on this topic.
atag, these use cases seemed to be entirely not semantic at all.
I think that Chris’s suggestion really makes sense. It is kind of fun to change my way of doing things. I had an unordered list that just contained an anchor tag with
lielement that was being set to
display:block. I changed that so that the
lielements themselves were clickable. It actually turned out to be a lot simpler.
Am I missing something? How did *you* made li to be clickable? I thought *every* element is clickable already :)
The problem is that, by default, only the anchor element has a distinct clickable look and behavior that users recognize and browsers follow.
Otherwise, it just takes a bit of JS code.
One more thing. You need to be in the habit of providing a progressive enhancement, web site or we app, as a good programming technique.
With that, I’m saying you’re not doing it right by using just the naked li elements.
Sorry, I meant focusable, not clickable.
I think the truth is somewhere in the middle, about required JS support from the user.
If the name is big enough, it can dictate the terms and forget about a few whiners. But I see this stance as detrimental.
From what I experience, Google made the right choices, going basic to start with, then pretty and enhanced for those willing to experience a full blown interface.
If you choose to go with an element that isn’t normally interactive (
span, etc.), remember to set the appropriate role on the element (e.g.,
role="button", or the more generic
role="command", etc.) so that accessibility software knows what you’re doing.
Good point. Thumbs up.
Google page speed docs state that you should “Avoid the :hover pseudo-selector for non-link elements for IE clients.”
Well, on the other hand, gmail is unig divs!
But I still would prefer anchor tags.
I think this is because :hover on other tags were not working in IE6-
Anchors = www world wormholes. Connecting two points in local or remote HTML web pages space. Even when JS is not available.
Otherwise, I agree with Chris and Google. If it’s web apps we talk about, any clickable element and their mother will do: input, button, div, span etc.
Though I have to say it’s a progressive enhancement we’re talking about. Some web apps, like Google Translate, GMail will work even w/o JS.
Definitely use a <button>, because it means “this will invoke an action”. A link (<a>) means “this is a hyperlink. It will take you to another page/resource”.
Never choose the element based on its default styling. This is no different from (say) using <h2> for top-level headings because “the font is too big when I use an <h1>”. You can easily make buttons look like links, if that’s what you want.
And if you must use the wrong element, at least throw a bone to screenreaders and add
role="button", as TJ Crowder mentioned.
See this video from YUI Theater: Common Accessibility Mistakes
Quote from 14:50 in:
“When I have a link, a link says “I’m gonna go to a new page.”; and so it’s gonna tell me where is that page.”
I don’t know about this. There are some nuances here to be noted.
The <a> element is what he means by link, but link means more: <area>, <link>.
And <a>, as an interactive content element, can point to a resource on the same page.
Excerpts for the specs:
“Links are a conceptual construct, created by a, area, and link elements […]
There are two kinds of links in HTML:
Links to external resources[…]
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor).
If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant.[…]
If a site uses a consistent navigation toolbar on every page, then the link that would normally link to the page itself could be marked up using an a element:
<li> <a>Examples</a> </li>
Notice the missing href attribute.
Yes, there are nuances — such as links jumping to somewhere else on the same page (i.e. in-page navigation).
None of the nuance changes the essential nature of a link, or of a button:
— Links are “go somewhere” interfaces
— Buttons are “do something” interfaces
– Links are “go somewhere” or “go somewhere and get something”.
Otherwise, it’s true what you’re saying.
Does div:hover work on IE6?
No it doesn’t work.
Great discussion folks!
Here’s more thought by Ryan Fitzer: http://ryanfitzer.org/2011/08/to-be-or-not-to-be-an-anchor/
I used to anchors way too often trying to get :hover support out of ie6 on elements that were not actually linking anywhere.
Now that I don’t have to worry about ie6 I don’t ever do this.
What about <command> tag? It’s not supported for all browser, but maybe it will be good solution for this problem.
I will prefer to use anchor tags because some browsers behave differently for events on div tag.
I see a lot of valid points but what do you do when you’re building an HTML/JS audio player vs. a flash audio player. For example, I’m currently developing a UI for a client web app, and one page has a audio player element that will play voice messages. It has a Play/Pause button, previous message and next message buttons, as well as a message elapsed/total time display. It also has a search field for searching for a specific message.
I’m currently using this code to mark it up, but to me it doesn’t feel write, and then there are also the box model issues with the <button> tag.
I had changed the markup a few times, initially using <a> tags, then <div> tags, and finally after doing more searching and reading a few articles/posts I landed at <button>.
What would I be best off doing, because for me it’s a constant battle in my mind over which is the RIGHT way to do it. Accessibility is less of an issue due to the fact that our client’s target demographic for the app will be MD’s.