For the love of all that is holy, can you all please start using `<a>` for navigation and `<button>` for actions, not the other way around?

Please don't make me turn this into a blog post.

Signed, someone who couldn't right-click to "open in a new tab" when it mattered.

#HTML #accessibility

Well, this gained traction. Guess I am writing that blog post. 🤓

@mahryekuh I didn't think devs needed a(nother) blog post to understand this quite simple concept 🫠

But experience confirms many web devs still don't understand, it seems. So, thanks for doing your part 🫡

@maybeanerd I joked a while ago that with the way people treat link versus button, it feels like subject that requires a PhD.

You asked, and I delivered. New blog post online:

"HTML link, or button, that is the question."

https://marijkeluttekes.dev/blog/articles/2024/11/04/html-link-or-button-that-is-the-question/

#HTML #accessibility #webDev

HTML link, or button, that is the question / Marijke Luttekes

Did you know that HTML links and buttons are not interchangeable? Learn more about their proper use cases in this article.

@mahryekuh well dang, I've been doing <a href="#" onclick:"javascript:dothething(); return false;">this</a> for twenty years, cheers for the update
@mahryekuh not really relevant for my teacher peers building out their Canvas courses usually, but I'll still read it and use it in a blog post I'm writing oriented towards accessibility in courses! Thank you for the post. :)
@Moosader Thank you! Feel free to send an update once the article is out.
@mahryekuh Great summary, clear and effective. (And happily for me, consistent with what Ive been saying) I'll send this to my current students and add it to my reading list for future semesters.

@mahryekuh you can do cursors with CSS, too.

I have one more point I may need to get back to, but great article, especially for categorically damning <a href="#" with good reason.

@mirabilos Before you get back to that other point; if it’s of the same level as setting cursors in CSS, please spare yourself the effort, I am aware of that.
@mahryekuh no, it’s about the inputs (specifically, checking if their button variants work on text browsers)
@mirabilos Now that sounds interesting.
@mahryekuh yeah, and somewhat important, will be in a bit as I need to get to my laptop first. The CSS was just a minor thing I noted.

@mahryekuh I tested vaguely-recent-but-not-too-new versions of lynx, links+ (links2) and www-wo-miru (w3m) successfully. Dillo showed the button, but it somehow did not let me enter text into the text field in the form, so I couldn’t test it. (I probably should test Dillo 1.x as well; Dillo 3 as maintained by @xtaran is rather new still, even if it’s the pre-handover version.)

I have no way to test Arachne, which is the main browser under DOS; I know there are people on Fedi who do… pinging a few I can see from an instance-local search have been running Arachne recently (my apologies, and feel free to ignore, if you’re not interested): @nina_kali_nina @phlash @foone

I’ll likely personally stick to <input type="submit" but evidently there’s no reason to avoid the <button variant for contemporary text browsers, so that’s good.

@mirabilos @mahryekuh @xtaran @nina_kali_nina @phlash @foone regarding `<button>` and `<input type="submit">` or `<input type="button">` there is a stackoverflow question about it: https://stackoverflow.com/questions/469059/button-vs-input-type-button-which-to-use
<button> vs. <input type="button"> -- which to use?

When looking at most sites (including SO), most of them use: <input type="button" /> instead of: <button></button> What are the main differences between the two, if any? Are t...

Stack Overflow
@xtaran @roytam1 @phlash @nina_kali_nina @foone @mahryekuh this was about <button type="submit" which apparently is better stylable than <input type="submit"

@mahryekuh You have a typo:

> Be aware that I will use the words "link" and "anchor" to refer to the HTML <a> attribute, ...

"attribute" should be "element".

I'd also suggest hiding the line numbers in code snipppets with `aria-hidden`, because they prevent screen readers from conveying indentation properly. A solution that makes the line numbers more accessible would of course be better, but I don't know of one on the web.

@mahryekuh Beyond that, despite my thoughts on the other thread, this is a good article on the topic.
@jscholes Thank you. Much appreciated!

@jscholes Thanks. The entire code block is a disaster (visually as well) and I don’t control the output. It’s one of those legacy things I’ve been meaning to fix for longer than I care to admit.

My apologies for the bad experience. Once I have fixed some other style and JS related stuff, this comes next.

@mahryekuh

> One of my top annoyances with websites is when I want to open a link in a new tab and find out that I can't.

This! Exactly this! Even large websites break this pattern regularly. Makes me mad everytime!

@mahryekuh
Different keyboard nav too. Enter activates a link, while space activates a button.
@paulox
@mahryekuh This article matches my long-standing intuition about when to use a link versus a button. But I actually got some pushback on this, from a screen reader user who isn't a developer. We were discussing a UI where there was a list of links to items in a typical CRUD scenario, followed by a link to a form to create a new thing. He wanted that last link to be a button so it would be easy to jump to it, skipping the list, with a screen reader's "next button" command.
@mahryekuh Since he's not a developer, he quite reasonably didn't care that I was following proper HTML semantics, or working with the grain of the platform, or whatever. He just wanted a particular user experience. I satisfied him by adding role="button" to that last link.

@matt If it was an app for literally that one user, it seems like a perfectly reasonable compromise to make. If not, I would disagree with it as a strategy, and inform the user about the "jump to the end of this container" command if their screen reader had one.

I might do the last thing anyway, because that particular command is extremely useful and sadly underused. But changing the role to button means users don't know it's a link, and hence don't expect to be able to open it in a new tab, bookmark it, etc. @mahryekuh

@matt Having said that: if it was an app for one person, I'd also ask them if they'd prefer a hotkey to activate the "new" button from anywhere on the page, which potentially would be even more efficient. @mahryekuh
@mahryekuh BLOG POST BLOG POST BLOG POST BLOG POST BLOG POST BLOG POST! ✊
@carlton Damn it, Carlton, I was drinking tea and nearly choked there.
Marijke Luttekes (@[email protected])

@[email protected] Sad code makes me sad. We need to educate people better. I guess Carlton was right; we need a blog post. Fine, I'll write one. 🤦🏻‍♀️

Fosstodon
@carlton This is one of those accessibility 101 things that's been written about tens of thousands of times. As much as I enjoy Marijke's writing, the accessibility community has a problem if it needs individual developers to keep regurgitating the basics again and again. I see some discoverability parallels with the content in your latest newsletter here... @mahryekuh

@jscholes @carlton Yeah, hard agree, James.

I also don't have as much reach or expert knowledge as the "big names" out there, but I'll do what I can.

Not gonna lie; I don't like writing this article, though. It's not my best work and it's actual effort. But if you want to slap someone with some rules, you better have them written down somewhere. 🥲

@jscholes @carlton It doesn't help that the average IT article and documentation suffers from the "Curse of knowledge" and happily skips over the foundations of web development.

https://en.wikipedia.org/wiki/Curse_of_knowledge

Curse of knowledge - Wikipedia

@mahryekuh I guess I don't agree that your name absolutely must be on something just because you're the one "slapping down" some rules or suggestions. You didn't want to write it, and someone else already did. But I'm not a blogger... shrug.

https://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html

@carlton

Links, Buttons, Submits, and Divs, Oh Hell

Screen shot of the Zurb Foundation advice for accessible buttons, where it shows anchors and a div each with role=”button”. In short, a perfect example of everything you could do wrong. NOTE: This was version 5.5.3. Most of this is fixed in the current version as of this writing (6.1.2).…

Adrian Roselli

@jscholes @carlton Well, my blog is also part of my marketing so it's nice to have some articles there.

I will link Adrian's article, though, since it's excellent. Thank you for the reminder!

@mahryekuh @jscholes there are many Django tutorials. Always room for one more. Likewise here I’d imagine.

@carlton I don't think they're directly comparable.

Django has a canonical set of official docs to refer back to, as well as the code itself. Many tutorials are written to make those things more approachable, or tie multiple strands together in ways people may not find obvious. The information quite often (though not always) does already exist elsewhere, and that state of affairs provides a nice progression story for people wanting to dive in in more detail.

In accessibility, a lot of the literature out there is reactive rather than proactive. I include WCAG in this, which many people might point to as a canonical work. But in truth, it was written as an attempt to make sense of very messy things and get them down in writing, but the scope is extremely limited (and quickly becomes outdated). And with less content overall, there are less opportunities to cross reference.

That last point might sound like I'm encouraging more writing, rather than less. But there is a huge imbalance between "basic" topics that have been written to death, and more advanced ones that have zero resources (mostly because people get paid to consult on those and don't/can't write anything down).

@mahryekuh

@jscholes @carlton Insightful as always, and I can't argue with this one.

I am only unsure of how to proceed with this information.

@mahryekuh I dunno really. Personally I'm going to eat an omelette and not worry much about it beyond the general, ever-present undercurrent of disabled despair. @carlton

@mahryekuh Also, just to be explicit:

Having worked with you, it's a joy to meet a developer with such a positive accessibility focus, who brings so much willingness to learn to the table. I don't want to discourage knowledge sharing, but people who take too much responsibility on their shoulders provide a constant story of burnout in the accessibility space. @carlton

@jscholes @carlton Thank you! Carlton is a fun one to tag here since he gave an excellent presentation on surviving open source for Djangonaut Space!

Don't worry about me; I've wanted to write this article for a while. It's just not my favorite one.

Thank you for the kind words.

@jscholes @carlton @mahryekuh The frontend community has a problem, rather than the accessibility community, I'd say. And here we can see why "I learned react and can use divs as JavaScript hooks" doesn't make one a frontend dev. In fact it poses one as far from frontend as can be.

Using a button instead of a div without knowing anything about the consequences and considering that as semantic HTML makes things even worse.

@jscholes
There's 2, maybe 3 browser engines, why can't we open a button in a new tab? Browsers know what middle clicking a link means, and they do nothing if you middle click a button. (Maybe duplicate the tab and then "do" the button's action?)

Seems like total nonsense that every site gets to specify their links open in a new tab but I can't just because of the tag they choose to use.

Why should devs be allowed to decide?

(also, where is my "open in this tab" option?)

@carlton @mahryekuh

@mahryekuh You mean this isn't the right way to link to to another page?

```html
<button type="button" onclick="{% url 'polls:generate_404' %}">404</button>
```

(Don't worry this wasn't me)

@nanorepublica Sad code makes me sad.

We need to educate people better.

I guess Carlton was right; we need a blog post.

Fine, I'll write one. 🤦🏻‍♀️

@nanorepublica @mahryekuh you need more tailwind classes to make it look realistic
@bmispelon @nanorepublica Baptiste, you enrolling in Django project website working group when?
@mahryekuh @bmispelon surely joining the accessibility team right? 😜😉
@mahryekuh @nanorepublica Maybe once it actually exists 😁 (it's still in the proposal phase afaik)
@mahryekuh
This so much! 🙏
Also I honestly thought you were going to say
"Don't make me turn the internet around!"
@mahryekuh
I just hate, when the middle-click doesn't open a link in another tab, but starts scrolling or pasting (depending on my OS).
Extra points if I don't notice it right away and want to have a look into the content of the (not-opened) tab and have already closed the original site or scrolled miles away in the meantime. Aaaargh!!
@mahryekuh I for one would honestly appreciate a blog post because this is the first time I've ever heard of <button>
@ifixcoinops Working on it!
Marijke Luttekes (@[email protected])

You asked, and I delivered. New blog post online: "HTML link, or button, that is the question." https://marijkeluttekes.dev/blog/articles/2024/11/04/html-link-or-button-that-is-the-question/ #HTML #accessibility #webDev

Fosstodon

@ifixcoinops
Same here. I think <button> may not have existed when I learned HTML.

@mahryekuh
If I rt-click & choose new tab, things have already gone badly. Control-lt-click is faster. But that often breaks & I’m not sure what garbage broke that but then rt-clicking is my refuge.

I think in the rare times rt-click»new tab failed I simply left-clicked & the browser put it in another tab anyway. Still annoying. If it were to overwrite my tab, I would do a control left-click on the BACK button

@mahryekuh just having `target="_blank"` in `<a>` so they open in new tabs when clicked is so much nicer.

@Alkaris Thank you for this segway!

Using `target="_blank"` is discouraged for accessibility reasons, as it removes a user's choice to open a page in the current or new tab.

That being said, you can probably make this behavior toggle-able with JavaScript and allow a user to set this is a setting.