My rule of thumb: if you could ever imagine a user wanting to control-click open in new tab or right-click open in new window, it should be a link. It's infuriating how many modern sites don't let you do this when the thing you're clicking on clearly ends up displaying a different view that you can independently navigate to in another tab or window.
The thing that bothers me about this whole insistence that, for accessibility purposes, it is <i>vitally</i> important that we correctly employ links and buttons to ensure that users of assistive technologies can correctly anticipate whether an interaction will <i>go somewhere</i> or <i>do something</i>...<p><i>Why do only assistive technology users get treated with that level of respect?</i><p>Because let's be clear - for sighted users interacting with this person's webpage, whether the markup is a link or a button, they evidently plan that visually it's just going to be a paint roller icon, inside an area of the screen of indeterminate size which is going to be somehow interactable.<p>Apparently it's not important to consider whether I, a user not currently employing assistive tech, might need to know before I click it whether that control will cause a page navigation, carry out an operation, or what.<p>It might be a link; it might be a button; it might just be a decorative picture of a paint roller. It might interact on hover, on click, or on double click. Who knows!<p>This definition of <i>accessibility</i> as something distinct from <i>usability</i>, where frontend devs will torture themselves over the semantic markup that they use to ensure clarity of purpose for accessibility purposes, has somehow become completely divorced from the world of UX design, where visual indications of affordances are no longer seen as valuable.
I actually think the link solution in the Codepen box shows perfectly what's wrong with the link solution: Links should (and do by browser default) maintain their history state, while buttons do not. If you don't want to maintain the change in back button state, don't use a link.<p>If in his link example I click the "Open Theme Controler" link, then click the "Close" link, and do that a couple times, when I then click the back button to come back to Hacker News, I'm instead cycled through the number of times I clicked those links. I doubt any user would expect that to happen.
IMO:<p>If it makes sense to "open in new tab" then it should be a link. Otherwise it's a button.<p>Corollary: If it's a link then middle-clicking on it better open it in a new tab! There are way too many times that this was broken by JS with the href just being set to "#" or something, but clicking the link, copying the new URL, opening a new tab, pasting the url, going back to the original page and hitting "back" did exactly what I wanted. Don't do this!
So when do I use `<div onclick>`? /s<p>It’s disappointing how developers are so lazy to not even know the basic concept of a link. It’s completely ridiculous yet super common to see click handlers on DIV elements that set the value of location.href<p>As for A/BUTTON, we really need an attribute that clears the button’s style entirely, safely and forever. Nobody knows how to properly and full drop all useragent styles from a button, try googling it.
Default computer peripheral behaviors to please not mess with:<p>- right-clicking defaults
- scrolling defaults
- Back/forward browser buttons to traverse _state_ as the user expects
- tabbing (and leave the damn default outline!)<p>If it's not a video game, please don't F with my keyboard and mouse's default behaviors. Thank you.
This button should have been a <details> <summary>.<p>And this rule of thumb is also incorrect (albeit by technicality). A form submit button goes somewhere (to the action response) and is a button.<p>I agree with the sentiment though, in general:<p>- If you are navigating through the page, use a link,<p>- if you are performing an action, use a button, (and in addition)<p>- if you are reveling some information, use a <details> <summary>
I think it must be a link if you would expect user want to open in a new tab, no matter it pushes history (navigation) or replaces history (in page tab).<p>There are countless of times that middle click to open new tab didn't work because page author use <button onclick="location.href='xxx'> as link. It's such an awful experience.
Not to get off-topic, but in the site footer the author mentions he's the developer of:<p><a href="https://polypane.app/" rel="nofollow">https://polypane.app/</a><p>Has anyone used it? Thoughts?
One major problem here is the mixup of UX and technical implementation details. From UX point of view, the link example goes nowhere, it just opens a dialog. From that point of view it the fact it uses anchors to do so is not really relevant.<p>From purely technical point of view, the question would be rather irrelevant as the distinction between a button and link is mostly how a human perceives it, it does not matter for the program.<p>This is likely an explanation for the awkwardness that the author mentions feeling of this implementation, and is supported by it not making sense to open this kind of a "link" in a new tab (because it does not go anywhere).
Square.com uses similar looking links and buttons in a dark pattern to trick users.<p>Login and land on the Home page. You want to look at transfers to your bank account (Balance > Account). Here you see big blue link box taking your to Balance: <a href="https://postimg.cc/yD97T8yT" rel="nofollow">https://postimg.cc/yD97T8yT</a><p>Sometimes this blue box is a button to initiate an early transfer, which triggers an additional early transfer fee: <a href="https://postimg.cc/t1jpvGrG" rel="nofollow">https://postimg.cc/t1jpvGrG</a><p>Once you get to the Balance page, you still need to find the link taking you to the Account page (View All Transfers) to actually see your transfers. Square takes a second stab at getting that fee with a big blue button in the middle of the page: <a href="https://postimg.cc/bG98KVMD" rel="nofollow">https://postimg.cc/bG98KVMD</a><p>Now perform this same action several times a week, all year round, and you will make the mistake and press the transfer button.<p>It only takes once for you to have a never ending enmity towards Square for filching $25 from your income.<p>I was caught the once in October of 2021. I *recall* the transfer was initiated immediately (and the extra fee of 1.5%). Since then I've revisited the button when the transfer was low, and I was willing to risk $5 to get a screen shot of the next page. That time I did find a confirmation screen (I can't find the screen shot now).<p>I call support, but they would not refund the transfer, despite having pressed it by accident, despite having never used the feature before, and having over five year relationship with about 200k/yr in sales going through their platform. "But you're getting the service" was their reply.
I’ve written a tutorial on building one of these that uses a checkbox.<p>There’s more ways than a button or a link. Some people have suggested in the comments using details and summary.<p>It works without javascript, represents the states open and closed without requiring any aria attributes and some other usability features people might find interesting.<p><a href="https://endtimes.dev/html-and-css-only-multiple-color-scheme-picker/" rel="nofollow">https://endtimes.dev/html-and-css-only-multiple-color-scheme...</a>
I made a big button that does something by going somewhere. <a href="https://gloutir.com/" rel="nofollow">https://gloutir.com/</a>
Just make everything a link (a tag) unless you can't. Doesn't matter how it looks like. It can be some text with underline or it could look like a button.<p>Even if the button only does some action on the page, it could still be represented with a url. Sometimes it doesn't make sense. Then that's the time to use something other than an a tag.<p>If this were the default, most of this problem wouldn't exist.
WCAG is kinda subpar. Last time I reached out definition of "owned" element and found there are open issues still discussing about it. In application context, I wonder if desktop apps are really accessible and no one complains about, or just the web got really bad rep partly because they are more accessible..bad examples.
I used to be more adamant that links should never open modals and should be buttons. Until we ran into an action column in a grid having 4-5 items. Having it be all buttons would look ridiculous and annoy users with space usage. We went with link tags (some are true links and some are modals). Not a peep from users.
Sometimes it does both — e.g. when I use Front and click on an email, it does something. But I should ALSO be able to open it up in a separate frame, for long readings (in Front you do this by double clicking).<p>Is it good practice to use links, then intercept then with preventDefault when it should go somewhere AND do something?
I respect this distinction in almost all cases. However, login and signup feel like they deserve to be styled as buttons, perhaps because they are the first step of a flow that will eventually have side-effects. However, they are just links on the home page.
A stock broker once tricked me into to executing a trade when I visited a link they sent on email--no validation; no login; no confirmation beforehand. I visited the "unique URL", and that was it.
Dare I ask, in the title, what is meant by the word "it". The word is used four times. However the meaning does not seem consistent across each usage.