1

Common practice is for links to use the a element, and buttons to use the button element. But are there any cases (even if their edge cases) where a button, via Javascript, should behave like a link?

15
  • Should? I don't know if they should, but its' extremely common. As a matter of fact many of the "buttons" in this page (including the one you used to make this question) are actually a elements. Furthermore: I'd bet it's way more common to use a disguised as buttons than to use actual buttons (unless you mean something else). Just in case, guess this might be of interest accessibleweb.com/question-answer/…
    – Devin
    Jun 7, 2023 at 19:30
  • 1
    @Devin I think he's asking about the opposite case: not a styled like a button but button functioning like a link. Jun 8, 2023 at 3:31
  • Why even question this? No one benefits from mixing up behaviour of buttons and links. It makes it harder to implement, confusing for users and isn't necessary by any means.
    – jazZRo
    Jun 8, 2023 at 10:28
  • 1
    "This is why few people know about ARIA and friends". ??? Few people know about ARIA? Everybody I know knows about ARIA. That's a very subjective statement - both yours and mine. If you want an accessible website, hopefully you're following ARIA rule #1 and using semantic HTML. You can get a lot (sometimes all) of your accessibility that way. If the semantics don't exist in native HTML (such as a tree widget), that's where ARIA fills in the gap. All (web) developers should be familiar with ARIA. Jun 8, 2023 at 22:25
  • 1
    @KitangaNday, you almost had me that you might know or care a little bit about accessibility but saying "No company just rewrites there [sic] code to fit a minority" showed me how much you don't know about accessibility. The disability community is hugely underrepresented and marginalized which is why countries had to create laws to protect them (us). Not everyone has perfect eyesight or hearing or dexterity, and for those that do, it is most likely temporary because life happens, and if you're lucky, you grow old and naturally age into some disabilities. Feel free to respond but I'm done. Jun 9, 2023 at 23:19

3 Answers 3

6

Since you tagged this with accessibility, I'm answering from that perspective.

No

A link is for navigation and implies the browser's "back" button will take you back to the previous page.

A button is for actions, such as "add to cart" (which is actually an interesting case since most "add to cart" buttons, while they do add the product to the cart, they sometimes take you to the cart too so they perform an action and navigate you. But using the browser's "back" button does not remove the product from the cart. That's usually a separate button).

So from an accessibility perspective, when a screen reader user hears "button", they'll expect to perform some action and the browser's "back" button does not come into play. If they want to undo that action, they'll need a different button.

When a screen reader user hears "link", they'll expect to be navigated to another page and they'll expect the browser's "back" button to take them back to the previous page (unless the page opens in a new tab, which is a separate accessibility consideration).

9
  • 1
    This is true even if it wasn't tagged with accessibility. Screen reader users will be as confused as other users when a button behaves like a link and a link behaves like a button.
    – jazZRo
    Jun 8, 2023 at 10:21
  • Nope, this is wrong, you can set the button's ARIA role to link if I'm not wrong and that will allow the screen reader properly identify an element. Jun 8, 2023 at 16:04
  • @KitangaNday You are correct that you are wrong. While you could add a role to override the default semantics, rule #2 of ARIA usage says to not do that. Just use a real link. Also, setting the role does not give you any behavior. By default, a button allows both enter and space to activate it. A link only allows enter. By specifying role=“link”, that does not prevent the space key from activating the “link “. Jun 8, 2023 at 18:07
  • 1
    @KitangaNday Not sure how you code, but I follow specs, especially accessibility specs. If you want to treat them as "suggestions" instead of specs, that's your prerogative, but you should be very careful giving out advice that go against accessibility standards. Jun 8, 2023 at 22:18
  • 1
    "how would using ARIA attributes be ruining UX". Easy, websites that have ARIA are more likely to have accessibility issues, mainly because people using it don't understand how it's supposed to work. This is based on research. See the "ARIA" section of the WebAIM Million Analysis. It says "Increased ARIA usage on pages was associated with higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected. " Jun 9, 2023 at 23:11
2

Appearance of button can change from case to case. Based on your situation you can take decision using Secondary action buttons as link.

For example, Back button. Also attaching one sample widget I designed, where I used secondary action button as link (looks like a link).enter image description here

1
  • 1
    Nice example. That builds on my answer where I suggested that buttons should be actions. "download report" and "re-check score" are actions. The fact that they are styled differently is ok. One should not choose a link (<a>) for "re-check score" just because the styling for the link is the visual you want. One should use a real <button> and then style it to de-emphasize the CTA. Jun 8, 2023 at 22:31
2

Yes, but it depends on how you've set up your buttons.

TL;DR: since most buttons in CSS libraries are actually button elements and a good number of new single page applications use ReactJS and subsequently React Router, you can say that the buttons used to navigate using react-router are behaving like links, since they use the History API.

See, historically, almost all buttons were actually a tags with a lot of styling to give them the required look. The problem with using a tags is when you try to use them as buttons instead of as links. Since a button doesn't necessarily need to link to anything but can perform an action. Well if you skip setting the href attribute in an a tag, fun can be had. This is why you'll notice that some buttons add # to the link, this was to stop the fun that was experienced when you left out the href attribute.

Now, most CSS libraries have transitioned to using the button element most probably to avoid all the fun that occurs with using a elements as buttons.

Now given that a lot of web applications are put together ontop of ReactJS and ReactJS uses React Router for single page routing (changing the link without actually causing the browser to reroute you to that link), we can say that the buttons being used to "link" to other pages are links. But in truth they are buttons running javascript that does the routing.

4
  • 1
    Cool answer, and I learned something new. But I'd contend the statement "Most web applications use ReactJS." Most web applications are actually developed using PHP and jQuery, by far ;)
    – Devin
    Jun 8, 2023 at 15:22
  • @Devin I'm struggling to put together an argument, thanks bootstrap and wordpress :D Jun 8, 2023 at 15:59
  • well, on the bright side, WordPress is slowly moving to full React, Gutenberg blocks are built in React
    – Devin
    Jun 8, 2023 at 17:20
  • @Devin, yep, I had so much hope for this, I think one of the reasons most the devs I know stay away from WordPress is cause of PHP Jun 8, 2023 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.