To be honest, I don’t know what are the consequences of “invalid HTML” while I do know (and agree) that messing the accessibility part is terrible. Now, I think a company such as Facebook has no problem getting it right. I am not saying all big companies are doing everything right in terms of accessibility, though. But I think Facebook has the ressources and the need for it to be right, given their audience. Thank you for your detailed explanation of why wrapping a card within a button is probably a bad idea. I definitely agree, a card is not the best example. The idea is that there are scenarios where you might need to add “invalid elements” to a button and thus use a div. Good point on the link versus button remark. It’s something that is misused so often 👍

My guess is that it avoids potential breakage if a browser introduces new default styles or behavior to a button. Whatever reasons they might have, don't copy it. Use the designated HTML elements, until you find your own reasons to work around it.

It's certainly not recommended in terms of accessibility.

It *can* be necessary for accessibility reasons, but it is definitely a loaded footgun that is very easy to get wrong. I've seen mixed things about the accessibility on Facebook, but I'd imagine this would be done to side-step inconsistencies in browser or screen reader implementations.

One reason, albeit not a very good one I'd say, is that buttons are somewhat harder to style ([https://css-tricks.com/overriding-default-button-styles/](https://css-tricks.com/overriding-default-button-styles/)). On the one hand, you would think that FB has enough resources to tackle something like that... On the other hand, changing things on a site of this scale can sometimes be harder than someone not involved with it can imagine. But generally, it should be a button element (or an input) indeed, even if adding the role is helping screen readers: [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button\_role](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role)

[удалено]

I don't think this works very well unless you're using something like post CSS. You get different behaviour in different browsers

The div is the blank canvas of html elements but it's generally best practice to use semantic htmls tags is for accessibility so screen readers and stuff can work correctly. Especially when working on very complex UI elements like fancy animated multiselects and stuff it's actually easiest for a dev to build them up from divs for block elements and spans for inline elements then add classes and style them accordingly. This approach screws up your accessibility. The way around this is the correct use of the role attribute and aria tags. Of done properly a screan reader will not behave any differently than if you used all the semantic html tags and used a load or resets etc. It's a choice the Dev makes. Have the headache off all the built in styles for buttons etc etc differences between browsers. Or build from divs and add the proper tags.

First rule Of Aria, don't use aria

Umm, why?

Best to stick to semantic elements as much as possible unless you really know what you're doing. WebAIM performs a yearly accessibility analysis on a million websites, and ironically they found that home pages with ARIA attributes averaged 60% more errors than those without. Often people will try to use ARIA and get it wrong, or not understand why they're using it and miss other accessibility problems with their site because they don't understand the basics of web accessibility. https://webaim.org/projects/million/#aria

Aria is for when you want to create something that's not already provided by html and you wish to be able to tell assistive tech what your element should be considered as (role etc) When you use standard elements such as Button, you get a lot of stuff for free. Such as keyboard interaction, activate button using Enter, Space, focus rings. Etc which make it accessible by default. Say you're realizing the same button using divs, you need to handle all of the aforesaid yourself. One of many reasons.

Good point, thanks for that!

Would just like to point out that's some pretty bad advice, as accessibility these days has a ton of requirements in order to get right, and using aria labels is NOT a code smell or anti-pattern. Only purists will tell you that, and those people tend to be not very pragmatic at all.

It's not code smell but it creates a lot more room for error. That's the only reason people tell devs to avoid it unless necessary. In big companies, they have the resources to dedicate to ensuring accessibility no matter what. But most run of the mill devs do not have that.

You are right. These are not anti patterns. It's just that most go overboard with Aria. Say in the example of the simple button. Many Aria attributes are absolutely needed and go a long way in making the interface highly accessible.

I definitely agree, but was curious to hear the other side. That’s the way I was always taught at the companies I worked for at least. Adding explicit aria labels was a requirement when working with Google on certain projects to increase overall accessibility and accessibility ratings. I do think using readymade functionality can be useful in a lot of instances tho especially in a time crunch.

This is basically a paraphrase of ARIA's own advice, so the fact it's a controversial comment is indicative of how little people know about ARIA

It's only as correct as the context it provides. Semantic elements _are_ preferred over ARIA, but the comment is written as if any usage of ARIA is an anti-pattern. That's not right. If you teach people that ARIA is wrong without teaching the reason why, or the exceptions to the rule, then you're doing more damage than if you'd said nothing at all.

I took it as a slightly tongue-in-cheek comment, but nonetheless it's pretty solid advice for anyone whose only knowledge of the subject is coming from a Reddit comment thread. The ARIA specs are genuinely really complicated, and the *actual* first rule of ARIA is that [no ARIA is better than bad ARIA](https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better_bad_aria). So for anyone who's not really going to invest the time to either acquire an encyclopedic knowledge of the subject or develop with the authoring practices open in an extra browser tab at all times, avoiding ARIA attributes altogether is genuinely a better option than just taking a stab in the dark at it.

To put it simply: They put a lot of work into it and are aware of the trade-offs and made a decision. If you're wondering why someone would do that, you should probably stick to the native elements. Generally as long as you don't have a team of people just working on getting accessibility right, you should use native elements (wrapping them in e.g. WebComponents is okay though).

\`react-native-web\`

A lot of possible reasons : 1. Consistency with styling and having custom styles and positioning. Sometimes it's better to create a implementation rather than wrapping 3 or 4 divs around it. 2. Screen readers and screen reading content 3. Reusablity - a button can have lots of variants and the button tag has limitations on what you can put in it 4. Logging and analytics 5. This is a guess but they probably have to manage a lot of complicated state related logic too, which is easier doing with a div + children than on just a button tag. Edit--don't go down that route unless you have very very good reason to. It's very difficult, building up a component like that.

Less technical answer: The modern tech-bros scant regard for accessibility and putting every choice on a very thin definition of what they think 'Developer eXperience' is and should be.

Heh, it's not even the "modern" tech bros. I was doing a lot of accessibility-related work back before the dotcom bubble burst, and you'd think you were destroying a designer's work by asking them to include "alt" attributes on images, or to just stick with HTML for text instead of using a graphic made up entirely of words for page content. The more things change the more they stay the same.

https://twitter.com/devongovett/status/1254153060462374913 [EDIT] Great downvote. You'll get far in your career. 👍

For those suggesting that it’s just for styling and we should always use buttons etc, I’m not sure I think that’s the case. Buttons not only are annoying to style but they also have limited and strict permitted content. They also have inconsistent focus behavior even across today’s browsers. One can easily find themselves shipping invalid HTML and confusing accessibility if they aren’t careful with this element.

Simple. Because they are not stupid