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.

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.

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.

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.

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?

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

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.

@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.)

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.

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

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

Some great tips here.

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.

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.)

A, for the reasons given above.

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.

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'.

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.

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).

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.

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.

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
      

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.)

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

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

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.

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).

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

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.

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).

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

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.

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.

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.

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 ...

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 ..?

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?

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.

I'd have to agree with Roger.

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

I chose A because of it's accessibility support.

@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?

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)

btw, B.

Sorry for double posting.

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.

A because it is more accessible

A, because of all the good reasons given above.

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

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.

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.

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

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.

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

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?