stereoboosterRecently I wrote the article and I got a comment about it. The comment was about code snippet in the article, it basically said: use <button> instead of <div role="button" tabindex="0">, because it is best practice, and if you don't follow best practices code is bad.
I tried to start a conversation: I asked to explain the difference, but after this everything went south.
I feel frustrated about this thread, I would prefer to have a constructive conversation, so in this post, I want to compensate missed opportunity and write down how the more constructive conversation on the given subject could look like.
Code in question
const Label = styled.div("Label");
Label.defaultProps = { role: "button" };
Healthier debate
A: Why don't you use a button? This is a bad code because it doesn't follow best practice.
B: The real reason I don't use the button here is that it was copy pasted from another article. But is it really that bad code? What the difference between <button> and <div role="button" tabindex="0">?
A: Semantics and behavior.
B: Which kind of semantics are we talking about? Semantics is meaning, meaning doesn't exist on its own, it needs a receiver (audience). Meaning for who or for what? I will go on and assume that recievers, in this case, are a11y applications (like screen readers).
Adding role="button" will make an element appear as a button control to a screen reader.
-- MDN
So my conclusion is that they both have the same semantics from the a11y point of view. Can you be more specific about the difference in the behavior?
A: keyboard friendly (responds to enter and space and focusable), disabling via fieldset, different states (:active, :disabled, :focus).
B: Ok. I copy pasted this code from my other article about how to write accessible accordion and my code is keyboard friendly (thanks to tabIndex=0 elements are focusable), I don't need disabling via fieldset (my component doesn't allow to disabled accordion panels), I don't need :active state because I show it with arrows up/down (▲/▼). Is it fair to say that code is bad anyway even though it follows WAI-ARIA spec?
A: Yes, it is bad practice, because with a button you would need less JS code.
B: Ok, let's compare line by line
<button |
<div |
element itself |
|---|---|---|
| type="button" | - | prevent form submit |
| - | role="button" | add semantics |
| - | tabindex="0" | make element focusable, to be fair I need to "undo" focusable state for some buttons with tabindex="-1" so it's a draw |
| {padding: 0; background: none; border: none} | {display: inline-block} | reset styles |
| - | onKeyDown for enter and space | I need to handle onKeyDown to support up/down arrows, home, end so it is just one more switch case |
That is not much more code.
A: Still bad practice, because it is not extensible, what if you would need to support the disabled state in the future you would need to write more code, where is with the button it would work out of the box.
B: I agree that to use button is the best practice in this case (agreed with it even before the conversation started, as you saw I posted a link to my article where I wrote about button). But this best practice doesn't justify calling this code "bad", because you don't know which requirements this code has.
A: Are there cases when <div role="button" tabindex="0"> would be better than <button>?
B: There are some edge cases
case 1:
Firefox will, unlike other browsers, by default, persist the dynamic disabled state of a
<button>across page loads. Setting the value of the autocomplete attribute to off disables this feature. See bug 654072.
-- MDN about button
case 2:
In Safari <button type="button">s are not "tapable" e.g. you can't reach them with Tab button, tabindex=1 doesn't help (I tested it Safari version 12.0 (14606.1.36.1.9)). But <div tabindex=1>s are "tapable".
The end
Conclusion
I agree that in most cases it is good practice to use <button type="button"> as a button, but this is a rule of thumb. There are edge cases when the rule doesn't work. I don't think it is possible to judge code out of the context (maybe in some very simple cases) - you need to understand requirements and reasons behind it.
What went wrong?
Aggressive start and defensive response
As you can see conversation (from Healthier debate) starts and ends with the same question "why button?". Why it doesn't arrive at a conclusion sooner? Because the first statement contains attack ("the code is bad"). So second response is defensive ("What the difference between <button> and <div role="button" tabindex="0">?" Can you prove it is bad?)
Alternative example
TIL
The type of the button. Possible values are:
- submit: The button submits the form data to the server. This is the default if the attribute is not specified, or if the attribute is dynamically changed to an empty or invalid value.
- reset: The button resets all the controls to their initial values.
- button: The button has no default behavior. It can have client-side scripts associated with the element's events, which are triggered when the events occur.
No argumentation
How one suppose to understand the POV of otherone without details?
Alternative example
2) can you substantiate claim?
7) Ad hominem
2)
- React isn’t interoperable with Custom Elements v1
- Synthetic events don’t completely mirror browser events
- No support for passive events
- Odd behavior with autofocus
- Doesn’t mirror handling of crossOrigin properly for img
There’s probably more. In short problems arise because React implements different event and attribute bindings leading to unpredictability with browser API.
7) At times it seems like prominent members of the React community act like the web begins and ends with React. I don’t agree. I also don’t see this kind of attitude in other JavaScript framework communities. It matters how the people in a community act. Coding is as much about the people as it is the code.
If you use React and love it then keep using React. This isn’t about you. This is about why I avoid a popular framework. I’ve used React. When it first appeared on the scene I was really interested in why they would implement a front end framework this way. I even built a similar framework from scratch that implemented a virtual DOM. Then I realized well the DOM is already a tree. Why do I need to duplicate it? I rationalized that the whole premise for duplicating DOM was flawed. If DOM was not performant then shouldn’t it be the browsers that implement better performance? We don’t need JS frameworks to take up that mantle. A few years later that panned out and browsers have optimized several things. On top of that there are now several ways to declare a component and custom elements are the path forward in my opinion. That isn't to say a library like React still won't be useful. Custom elements still may require some pattern for managing state in your project. But that paradigm is much more for Redux to handle than React IMHO, or some other state pattern.
I don't agree with it, but I understand argumentation. As well I learned something new. I chose not to argue in this case, but I could...
I'm wrong as well
I'm no saint myself, I got triggered the other day:
I mean if your main concern is "Client wouldn't give 2 shits about how is that working", I guess this advice is not for you.
I'm not saint myself, but from time to time I think about people who have special needs, for whom internet (the biggest source of information, free education, online banking, social, media etc...) is not accessible. There are people who can't use internet, because somebody "didn't give 2 shits", and other person didn't bother either, because he is not get paid for it.
W3C Validator? Seriously? Did you travel here from 1999?
UPD: W3C Validator is ok, it is not for a11y testing though. You can try axe for a11y testing. a11y testing tools doesn't guarantee absence of a11y issues, they just help find some obvious ones. You still need to test it manually
The phrase "W3C Validator? Seriously? Did you travel here from 1999?" is inappropriate, I regret I said it.
I want to be more patient.
Photo by FuYong Hua on Unsplash
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
You forgot the most important point about buttons from an accessibility viewpoint. Using
type="button"when you aren't using it to submit data!If you forget this type, some browsers default back to
type="submit". By also using proper type you don't neede.PreventDefaulteither.If you want to get better at #a11y development I would focus more on HTML symantics and what changes when you add aria elements because it can change the behaviour of elements and their intended meanings to users.
To learn more I would highly recommend readying Hedyon Pickering's Accessible Components. It's mandatory reading for all our frontend Devs at our shop because we're a charity that needs to build accessibility into everything we do.