Can you explain the use-case here? What about "being a button" do you need for the desired functionality? You just want it not to look like a button, while still acting like a button and looking like a link?
So if you want something that takes an action on the current page via JS but looks like a text link, it should be a <button> element styled as a link.
Here's a good, extensive article on the differences and use-cases for links and buttons: https://css-tricks.com/a-complete-guide-to-links-and-buttons...
As I thought, this use-case comes down to "How do I trick the user into treating something like a link when it's really a button?" Or, more generally, "How do I subvert user expectations for a website?"
How about, don't? Maybe the fact that it's hard to do within the web spec means you should re-think what you were trying to do?
On one hand, if I expect buttons, and only buttons, to have some non-link in-page effect, then yes, those [-] things should be buttons.
OTOH, as ratww, notes, the up/downvotes "are links", in a sense -- if JS is disabled, it just does the upvote with a page load, so functionally it's like a link and deserves <a> and not being a button. But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect.
So let's go with the "make it a button" implication. I tried wrapping the [-]s it <button> tags, and yeah, that gives the button styling, which doesn't fit with the HN general style -- I'd prefer it stay text.
So I grudgingly (and tentatively) concede there are things that semantically should be buttons but whose default styling I'd still want to excise right out of them, forcing me into that dilemma I previously ridiculed. But is there still a way that I'm wrong about that concession?
> But by that logic, nothing deserves to be a button because you could replace it with a page load + the desired effect.
Not really. For instance, for the downvote/upvote buttons (or links?) here I actually agree with mwcampbell, they should be buttons. I don't think my other answers don't apply to them, because they don't look like links anyway. They could even be submit buttons inside forms to keep the site working when JS is disabled.
And for the [-], couchand just suggested <details> and this is the correct answer for me now.
Oh, I agree on that point -- if it is legitimately a button, you should not make it look like a link. That's like you're trying to them into thinking the click will take them to a different page. (Among other problems.)
It's just that the issue of handling the [-] collapse icon caused me to realize there could be a use under those constraints.
>And for the [-], couchand just suggested <details> and this is the correct answer for me now.
Ah, wasn't aware of that. That seems like a better approach.
https://docs.microsoft.com/en-us/windows/win32/uxguide/image...
And a rectangular outline and/or background is of course the basic visual element that indicates a button.
The ASCII art look works well here, but that’s because HN has an intentionally lo-fi aesthetic. On an average site I’d say it should be changed to a real box. Not a plain unstyled <button>, since (depending on the platform) those stand out too much for a relatively unimportant UI element. But I think a styled one would work.
I don’t have enough HTML experience to know what the issues are with layout.
The [-] is more complicated. Ideally it would link to a non-js fallback, but alas. But it's much better as an anchor tag than as a button disguised as a link.
<div class="votearrow" title="upvote">Upvote</div>
Alternately, instead of having the grayarrow.gif as a background image on a div, they could use an img element so the alt attribute becomes the accessible name of the link. Editing it in my browser's inspector, it looks exactly the same:
<img src="grayarrow.gif" alt="upvote" title="upvote">
An advantage of this approach is if the GIF doesn't load, the alt text is displayed instead (in some browsers, not all).
If you want to leave the title attribute to show on hover, that's fine but it's only going to help a sighted mouse user who needs more than triangles to understand that clicking them will upvote or downvote.
Since there are many upvote buttons on a page, a standard accessibility recommendation would be for each to have unique names to differentiate them out of context, something like "upvote ratww message 23326798." If user testing was done with people who use screen readers, I suspect they'd say that's too wordy and these controls should not be used out of context therefore, "upvote" and "downvote" are fine.
There is some nuance to getting that right (forms). I think an <a></a> shouldn’t be used, because that is a GET action, which should be idempotent.
It should never be a button disguised as a link, however. Fake links are much worse than javascript:void(0), because they break expectations of users, and are more prone to breaking. At least with javascript:void(0) browsers are able to use it as a hint to disable certain context-menu items, and it's much better than having a fake link. For accessibility purposes, if you need button behavior but link-look you should use role="button".
And in case I wasn't clear, I agree with that.
Why? It really shouldn't look like a link.
The mere fact that it requires a 20-line-hack is enough proof that this is a hack. It subvert user expectations (example: it's a link that you can't right click, tab behaves differently), accessibility (example: it looks like a link but will register as a button to a screen reader) and will probably look different in some browsers.
If you indeed need a navigational link you can freely attach a onclick event to a link. If the link has no proper non-javascript fallback (it ideally should, though) you can link to javascript:void(0); and most browsers will prevent the "Open in New Window" option from showing up in context menus.
Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do.
I'm making exactly the same point as the article: using semantic HTML will get you accessibility for free.
If you need something that makes an action, then it should be a button but never disguised as a link. It should just look like a button. This way you won't subvert users expectations (you said it yourself: links are for taking users to another URL), and will still be accessible to screen-reader users.
If you need something that takes to another page, then it should be a link, even if it uses Javascript behind the scenes. This way screen-reader users will know it's a link taking somewhere else and sighted users will have the same experience.
-
> Using CSS to change the appearance of a button isn't a hack, that's the explicit purpose of CSS. It's a hack to make a link point to "javascript:void(0)" to prevent it from doing the thing it's supposed to do.
I disagree. MDN's CSS accessibility page starts precisely with this: "It is possible to use CSS to make any HTML element look like anything, but this doesn't mean that you should". [1]
Changing the whole look and feel of an element to emulate another is definitely a hack. You would also need aria-role="link" to have proper accessibility, btw. Which is exactly the point of the article: not having to sprinke aria-role just because you're using non-semantic HTML.
Ideally you would have a proper link instead of a fallback, so that users can open the link in a new window or save a bookmark. Using javascript:void(0) is less than ideal but at least gives a hint to the browser that the link is not taking the user to another URL.
[1] https://developer.mozilla.org/en-US/docs/Learn/Accessibility...
EDIT: Replaced bad argument with the MDN quote.
Your point still stands, if someone makes an element other than <a href...> look and behave like a link, they should also add role="link" to convey that role to assistive technologies.
https://news.ycombinator.com/item?id=22965184
I asked if book now should be a button or a link if it takes you to an ordering page, still not sure.