SnookSurvey #2: To Link or Not?

The discussion on this should prove interesting. So, you're ajaxifying an interface and you've got some JavaScript injecting new elements into the DOM for the purpose of enabling interaction. For example, you've got an FAQ with a series of questions and answers. Questions are marked up with H2's (or maybe you prefer definition lists for your FAQ, whatever, this is just for argument's sake). You hide all the answers and set up event handlers for users to click on the questions. But how do you make the interaction obvious? Do you:

  1. inject a link element (A) into the HTML and add the event handler to that; or
  2. add the event handler to the header and add a class name allowing you to style the header using a different colour and cursor:pointer.

Discuss.

Published June 06, 2007
Categorized as SnookSurvey
Short URL: http://snook.ca/s/815

Conversation

54 Comments · RSS feed
Kevin said on June 06, 2007

Definitely B. In A you're adding an anchor because you want the anchor's style, not the functionality. To me, it's like using <strong> because you want bold text. Adding a decent CSS class would suffice.

Jeff Croft said on June 06, 2007

I don't see a whole lot of difference between the two. They both seem equally accessible and usable. I'm sure people will have perfectly reasonable explanations of why one is better than the other, but my opinion is: it doesn't matter. Both are fine ways to go about it.

Yuccaplant said on June 06, 2007

Definitely A, because B ain't accessible from a screenreaders point of view. Moreover I think that it's a logical thing that every 'clickable' element is a link.

Roger Johansson said on June 06, 2007

A.

B is not an option for accessibility reasons, since it offers no way for people who do not use a mouse or trackpad to interact with your interface.

Arjan Eising said on June 06, 2007

B is definitely my answer. Because you don't hyperlink something, you only trigger an event. The a element is for links, not for events.
@Yaccaplant: since when do screenreaders care about JavaScript?

Rian Orie said on June 06, 2007

A
Simply because B doesn't degrade for screenreaders or I-dont-use-javascript-because-its-unsafe users :)

I'd probably make it a link that would show the answer after a reload and use javascript to hijack this functionality in without a reload

Paul Annesley said on June 07, 2007

Rian: I believe the answers will not be hidden in the first place for users without JavaScript. Keyboard navigation for JS-enabled users is still an issue if there's no link element to tab to.

Yuccaplant said on June 07, 2007

@Arjan Eising
Almost every modern screenreader supports javascript at some level (it's true that not every setup with an (old) screenreader supports javascript). Just don't forget to put focus on tne newly available content. (My blind colleague can confim this.)

kimblim said on June 07, 2007

A - no doubt.

Preferably constructed in a way, where you insert a url into the href of the <a> as well and put a return false in the javascript.

Martin said on June 07, 2007

A, because you can't use your keyboard to navigate between the elements if they're H2's.

Kevin said on June 07, 2007

Well, I've changed my mind. Apparantly you do want the functionality of the anchor. ;-)

Some great tips here.

Jack Sleight said on June 07, 2007

B,
Arguing over which of the two would degrade the best is irrelevant, because they are both being inserted via JS anyway, if JS was turned off neither would ever get added to the page.

In my mind <a> elements are for hyperlinks, not interaction. Given that there is no logical value for the href attribute in this situation, it makes no sense to add an <a> element.

flashpro said on June 07, 2007

A is the only right answer. You should use an anchor because the element is clickable and the right element for clickable items is an anchor, not a H2.

And off course this is more accessible... because screen readers depend on semantic code. But this is just one of the reasons (keyboard nav., search spiders, etc.)

Matthew Pennell said on June 07, 2007

A, for the reasons given above.

Jack Sleight said on June 07, 2007

Oops, that should read "In my mind <a> elements are for hyperlinks". There is also no need for anchors, because it sounds as though the answers are appearing directly under the questions anyway.

trovster said on June 07, 2007

Definitely 'a'. I understand why people argue for 'b', but a lot of this doesn't matter, because you're adding the element via JavaScript, so if you do not have JavaScript the code isn't broken, unlike using ::javascript in anchors within 'normal' static code.

The fact that if you didn't use an anchor, you'd have to fix :hover effects for IE6 using JavaScript (OK, you're already using JavaScript, but this is just extra hassle). Definitely 'a'.

Jake Archibald said on June 07, 2007

A - if I had to choose one.

Instead, I'd rather insert a list above the first question which contains all the question titles as anchors which link down to the appropriate part of the page. This is screen-reader and user friendly. The list doesn't really need to be generated by javascript, but it easily could be.

Jesse Skinner said on June 07, 2007

A, because then you can give it focus (ie. click it from the keyboard) as well as give it non-JavaScript "functionality" through the href (either go to another page or jump down to the anchor of the answer).

Jack Sleight said on June 07, 2007

I’ve been giving this some more thought, and decided on this:

B, unless there is a logical and valid value for the href attribute of the <a> element eg. anchors, or links to separate pages (“javascript:…” is not valid IMO). However in that case, it would probably make more sense to include the <a> element in the mark-up, rather than adding it via JavaScript.

steve said on June 07, 2007

Has to be (A), because you want users to be able to keyboard navigate to it.

But, the link could be bogus, with JS to expose the answer text... depending on layout, maybe a class makes sense, but likely just hiding/showing the next child elem should work.

Kasimir K said on June 07, 2007

The answer to "But how do you make the interaction obvious?" is C) <button>

Then again, speaking of this kind of FAQs, IMO the proper way to do it is:

  • two lists
  • in the first list just the questions
  • in the second questions and answers
  • the q's of the first list are links to the q's of the second list, which are anchors
  • now we have max usablility for UAs without JS
  • then enhance it with JS:
    • hide the first list

    • in the second list:
      • hide all answers

      • give event handler to all question anchors
Adam J. McIntyre said on June 07, 2007

Setting all thoughts of accessibility aside, as we can all agree that the end result needs to be accessible, I'd have to side with (B).

(A) seems to be adding extra markup to the page purely for the sake of taking advantage of that markup's inherent style properties; the extra markup is not really necessary, other than for presentation. Control that presentation with a bit of CSS and lighten that code a bit.

With (A), you'd be adding x number of anchor tags to your page's markup. With (B), you're adding a line or two of CSS (cursor:pointer/hand, maybe a text-decoration:underline).

(From an accessibility standpoint, I like Kasimir's idea.)

Nate Klaiber said on June 07, 2007

Another vote for A, for many of the same reasons listed above. Few other thoughts in my head, but A is my final answer.

Matt Robin said on June 07, 2007

Although B sounds intriguing it also sounds a bit much, I think I'd go with A.

alvin said on June 07, 2007

as noted above, it really depends on the way you inject the A tag. If source code remains unchanged and you use JS to inject the extra tags, it's beats the purpose of having it there in the first place - which is to provide better accessibility support. So in that sense, B would be a better/simpler choice.

I however, disagree with Adam's reply above that using the A tag just for the sake of the markup's inherent style properties. Some of the comments mention about keyboard and accessibility support. Also with an A tag, you can implement :hover state without extra javascript (just to make IE6 plays nice). The 'title' attributes provide additional acces. support.

Brendon Kozlowski said on June 07, 2007

Hmmm... I decided on (B) for my solution previously whilst using definition lists (and only inserting classes, not actual CSS), but I never thought about allowing the ability to set focus. If I were to also add focus, I'd still be completely happy with B. Unfortunately, I'm not sure how to do that (atm) so I'm personally unhappy with both solutions. I don't want to change the markup from a header to an anchor'd header (or a DT to an A).

Jarrod said on June 07, 2007

A without a doubt. ALWAYS design with graceful degradation in mind.

Rob said on June 07, 2007

I think (B) is definitely the ideal solution, but it simply isn't practical. I don't think there is any way to get keyboard focus outside of Gecko/Firefox and IE and even if there was, how would you indicate to a blind user that the item is click-able?

In a real-world situation, I think Kasimir's two list solution is probably the best method, as it's a little cleaner and less hack-ish than adding an anchor element only to co-opt it's behavior by not actually hyperlinking.

Lance Fisher said on June 07, 2007

Using method (A) you could make it degrade easily by having the href point to a page where the FAQ answer is located, but override the link with javascript to inject the answer directly into the current page.

On the other hand, I like that (B) has less markup. Also, you could make the H2 element keyboard-accessable by setting its tabindex to 0 or greater.

I was leaning more towards (B) for the cleaner markup, but I think for the purpose of easier degrade-ability I would choose (A).

Jonathan Snook said on June 07, 2007

To clarify things as I think a few people have misunderstood: in both A and B, we're injecting the required behaviour using JavaScript so degradation is not an issue. The issue is whether additional markup should be added just to gain the benefits that a link element gives you, despite the fact that said link won't actually link to anywhere.

Lance Fisher said on June 07, 2007

Oh, in that case, don't add the anchor.

Jeff Croft said on June 07, 2007

I stand my my original answer: it doesn't matter. Really, who cares? Both work great, and I can't see any practical, real-world difference. It's an interesting academic debate, but I don't think it matters in the real world.

Brad Touesnard said on June 07, 2007

It sounds like the page is already marked up semantically and you are just transforming the page for presentation, so it doesn't really matter.

However, I would lean toward (A) because you are actually transforming the header text into a link for presentation and by injecting an anchor tag it will inherit the anchor style you have already defined.

It makes no difference what you attach the event to.

Chris Lienert said on June 07, 2007

I've already come across this before and I chose B. Combining unique styles for the headers with the JS has worked well.

I can see how option A would assist with keyboard navigation, but given that the anchors' behaviour is hijacked, there's not much gain.

Daniel said on June 08, 2007

I really think you can't really go wrong with either.. Just make sure whatever you add the event handler to is obviously click able. Something beyond just a cursor change... but I would choose...

A.

Because you can make it an anchor for screenreaders, then have your event handler return true ...

Andy said on June 09, 2007

I'd say it depends on the target audience. Although, for accessibility, I'd go with A.
However, it doesn't make much sense to me encapsuling the H2 element inside a link when you could just simply make the link look like the H2 element using CSS. Unless there's some unknown factor to why we would have to use H2 elements ..?

Chandra said on June 10, 2007

My choice is A.
I am with Roger. B is not accessible for screen readers.
A link should be a link. Why simulate the link behavior for heading/dt using JS and CSS?

Jackson said on June 10, 2007

I would go with A and link the anchor to a page with the individual question and answer. That way users with javascript can show/hide answers till kingdom come, and users without can still access the answers.

Dylan said on June 10, 2007

I'd have to agree with Roger.

Medyk said on June 10, 2007

A.
We're adding interaction layer and it should be reflected in structure.

Choosing B would be like (more extreme example) adding form functionality but hesitate to add form element

Kevinin said on June 10, 2007

I chose A because of it's accessibility support.

Yuccaplant said on June 11, 2007

@Jeff Croft
In my case the real world difference is 1m83 tall, weights 81kg, is called Geert and can be quite aggressive with his white stick from time to time. ;-)

So yeah, it matters. Don't be selfish and think about blind people, think about people who don't have the physical ability to surf the internet with a mouse, ... .

As it comes to B, the arguments are only academical. So why go for B?

Dave Choi said on June 11, 2007

If you're concerning yourself with accessibility and anchoring for screen readers, the questions should all be anchored to begin with, regardless of whether the answers are interspersed or provided after an index of questions. That decision basically has nothing to do with JavaScript.

That said, you shouldn't inject anchors into adequately semantic HTML with JS unless you're doing something like linking to JS-enabled-only content.

(Incidentally, this has nothing to do with AJAX)

Dave Choi said on June 11, 2007

btw, B.

Sorry for double posting.

Mikel Ward said on June 11, 2007

B, because clicking on it doesn't take you to a new page (or an already visible section on the same page), therefore it's not a link.

I already use B on my links page, but I admit it's lacking something, perhaps something like the expand/collapse widget from the Yahoo UI TreeView would be even better.

Depending on the size of the content, it may be better to use CSS to hide the answers and use JavaScript to display them. You can configure the CSS to only hide the answers from screen devices, so screen readers will ignore them and see the whole content.

Nick Cowie said on June 12, 2007

A because it is more accessible

Andreas said on June 12, 2007

A, because of all the good reasons given above.

DreamwinD said on June 12, 2007

Both ways. All links will have "href" and "onlick=...return false;" attributes
double accessibility (ajax-mode and noscript-mode)

Jem said on June 12, 2007

I just wrote a brief tutorial on this at the start of the month for tutorialtastic and chose to go with A but with empty links (#). I chose this method for its simplicity and that fact that I wouldn't have to add a whole bunch of CSS and hackery (that the majority of my audience would barely understand) to make it look good.

If I were to code the same thing into a page professionally (e.g. for a business that therefore has to comply to various accessibility laws) I would probably also choose A, but would link the question to something - e.g. a page of its own. This would be more semantically correct, would allow people to view the question and answer irrespective of whether or not they had JavaScript installed and would also allow people to link others directly to the individual contents of the FAQ.

Steve said on June 12, 2007

I would have to go for A because it allows focus to be gained for keyboard-only users, but the questions should have terse anchor text for voice recognition users. Otherwise they might have to speak the full text of the anchor to activate the control.
If they are very experienced users of voice rec, they could just say "links" and have each anchor revealed with a numerical value overlay and select the corresponding #. You cannot count on the level of proficiency being equal in all your users.

Fredrik Wärnsberg said on June 18, 2007

A, combined with site anchors that make the JS act unobtrusively.

Jeff L said on August 21, 2007

I don't see this mentioned anywhere -

Roger wants option A just to allow the element to receive focus. Folks argue this is wrong, as it's not technically a link and doesn't go anywhere.

What about using option B but putting a tabindex on the h2? This would allow the element to receive focus. However, you'd need to use another event handler along with the onclick, as onclick won't fire when you hit the enter key, as it does for links. A onkeyup handler that checks which key was pressed might get the job done.

Tommy Olsson said on August 22, 2007

The tabindex attribute is not valid for headings, only for links, area, object and some form controls.

Stevie D said on August 22, 2007

I don't see how either of these options can be made accessible. At all.

If the plain page just lists the questions, and the answers are inserted using Javascript, then anyone without Javascript active can't get the answers, full stop. So neither A nor B, in the situation you've suggested.

A better solution would be to have a plain page generated with the answers, and put links to that in the initial plain page. Whether you have a page for each question/answer, or whether you link to, eg, "faq.htm?q=6" and use server-side code to insert the relevant answer into the question page doesn't matter - either way is perfectly accessible.

If you then want to Ajaxify it, you can do. And then, as you've already got [a] tags in your plain page, option A makes most sense. It allows non-mouse-users to select and activate the option and to see that it is selected, which is very difficult under B. It doesn't add any additional elements that aren't required by the initial accessible version.

PS - Is your blog deliberately set to prevent IE-users from contributing?

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.