8 ms·

Over-simplifying, but in general a link should take you to a different url/destination. So if you want something that takes an action on the current page via J

Over-simplifying, but in general a link should take you to a different url/destination. 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/ https://css-tricks.com/a-complete-guide-to-links-and-buttons...

SilasX 6y ago
That much I understand. But then, if you want it to act like a button -- do something on the page but not link anywhere -- why not leave it to look like a button so the user has the right expectation for what it's doing? 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?
- kall 6y ago
  Do you think the [-] link on this very comment should look and layout flow like a button?
  - deleted 6y ago
    [deleted]
  - mwcampbell 6y ago
    Yes. So should the upvote, downvote, and unvote links, because these things don't go to nw pages, and the voting links take immediate action.
    - ratww 6y ago
      I agree with you, but just a point: the upvote and downvote arrows actually go to other pages when you disable JS, so it makes sense for them to be <a> tags. They should provide better feedback though (and a title attribute for screen readers). 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.
      - robertoandred 6y ago
        No, it's the absolute worst kind of anchor link: it's linking to javascript:void(0). It should be a button. Not complicated.
        ratww 6y ago
        Read again. The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. It should have a title attribute and feedback as well, for screen readers. 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".
        mwcampbell 6y ago
        > The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. And in case I wasn't clear, I agree with that.
        a1369209993 6y ago
        The upvote link on your comment goes to [ https://news.ycombinator.com/vote?id=23327414&how=up&auth=51f460b4a5e8302f4ab6bf2d1dd7631902fab274&goto=item%3Fid%3D23327414#23327414 https://news.ycombinator.com/vote?id=23327414&how=up&auth=51... ] not [ javascript:void(0) ]. Are you sure you don't have RCE vulnerabilities enabled?
      - extra88 6y ago
        The title attribute is not a good way to give elements an accessible name for screen readers (except iframes, title attribute is the right choice for them). Better would be to put the text inside the existing div and use CSS to visually hide it (which does take ~11 properties to cover older and different browsers): <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.
  - SilasX 6y ago
    Let me first say, this is a really great discussion that has forced me to think, and I'm upvoting both sides, including Deimorz and ratww. 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?
    - ratww 6y ago
      My objection is more about making a button looking like a link, as in the linked StackOverflow answer. I stand by my post that this is wrong because you're subverting user expectations and probably making life harder for everyone involved ("why am I tabbing to this, this is not a button... why can't I right click it... aaaaargh"). > 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.
      - SilasX 6y ago
        >My objection is more about making a button looking like a link, as in the linked StackOverflow answer. 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.
  - couchand 6y ago
    No, the proper semantic element is <details>, just let the browser render the expand/collapse control.
  - comex 6y ago
    I’d say it already looks like a button. To me, [-] comes off as basically ASCII art for a box with a minus sign in it, similar to the classic Windows progressive disclosure controls: https://docs.microsoft.com/en-us/windows/win32/uxguide/images/progressive-disclosure-controls-image16.png 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.
ratww 6y ago
> 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. 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.
- deleted 6y ago
  [deleted]
- Deimorz 6y ago
  The entire subject of this thread is about getting accessibility and other benefits for free if you write semantically-correct HTML. You're arguing for the exact opposite: just using whatever element gives you the appearance you want, regardless of whether it's the correct one or not. 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.
  - ratww 6y ago
    That's not true. I'm not advocating that. 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/CSS_and_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Accessibility... EDIT: Replaced bad argument with the MDN quote.
dalore 6y ago
This is a similar discussion to what happened last month https://news.ycombinator.com/item?id=22965184 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.

SilasX 6y ago

That much I understand. But then, if you want it to act like a button -- do something on the page but not link anywhere -- why not leave it to look like a button so the user has the right expectation for what it's doing? 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?

kall 6y ago
Do you think the [-] link on this very comment should look and layout flow like a button?
- deleted 6y ago
  [deleted]
- mwcampbell 6y ago
  Yes. So should the upvote, downvote, and unvote links, because these things don't go to nw pages, and the voting links take immediate action.
  - ratww 6y ago
    I agree with you, but just a point: the upvote and downvote arrows actually go to other pages when you disable JS, so it makes sense for them to be <a> tags. They should provide better feedback though (and a title attribute for screen readers). 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.
    - robertoandred 6y ago
      No, it's the absolute worst kind of anchor link: it's linking to javascript:void(0). It should be a button. Not complicated.
      - ratww 6y ago
        Read again. The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. It should have a title attribute and feedback as well, for screen readers. 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".
        mwcampbell 6y ago
        > The point was that it should be a button that looks like a button, or a link with proper fallback for non-JS users. And in case I wasn't clear, I agree with that.
      - a1369209993 6y ago
        The upvote link on your comment goes to [ https://news.ycombinator.com/vote?id=23327414&how=up&auth=51f460b4a5e8302f4ab6bf2d1dd7631902fab274&goto=item%3Fid%3D23327414#23327414 https://news.ycombinator.com/vote?id=23327414&how=up&auth=51... ] not [ javascript:void(0) ]. Are you sure you don't have RCE vulnerabilities enabled?
    - extra88 6y ago
      The title attribute is not a good way to give elements an accessible name for screen readers (except iframes, title attribute is the right choice for them). Better would be to put the text inside the existing div and use CSS to visually hide it (which does take ~11 properties to cover older and different browsers): <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.
- SilasX 6y ago
  Let me first say, this is a really great discussion that has forced me to think, and I'm upvoting both sides, including Deimorz and ratww. 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?
  - ratww 6y ago
    My objection is more about making a button looking like a link, as in the linked StackOverflow answer. I stand by my post that this is wrong because you're subverting user expectations and probably making life harder for everyone involved ("why am I tabbing to this, this is not a button... why can't I right click it... aaaaargh"). > 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.
    - SilasX 6y ago
      >My objection is more about making a button looking like a link, as in the linked StackOverflow answer. 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.
- couchand 6y ago
  No, the proper semantic element is <details>, just let the browser render the expand/collapse control.
- comex 6y ago
  I’d say it already looks like a button. To me, [-] comes off as basically ASCII art for a box with a minus sign in it, similar to the classic Windows progressive disclosure controls: https://docs.microsoft.com/en-us/windows/win32/uxguide/images/progressive-disclosure-controls-image16.png 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.

ratww 6y ago

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

deleted 6y ago
[deleted]
Deimorz 6y ago
The entire subject of this thread is about getting accessibility and other benefits for free if you write semantically-correct HTML. You're arguing for the exact opposite: just using whatever element gives you the appearance you want, regardless of whether it's the correct one or not. 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.
- ratww 6y ago
  That's not true. I'm not advocating that. 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/CSS_and_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Accessibility... EDIT: Replaced bad argument with the MDN quote.

dalore 6y ago

This is a similar discussion to what happened last month https://news.ycombinator.com/item?id=22965184 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.