6 ms·

You don't add ARIA tags to the UI - you use UI elements which are already accessible. You should never, ever make a button out of a div. The JavaScript communit

You don't add ARIA tags to the UI - you use UI elements which are already accessible. You should never, ever make a button out of a div. The JavaScript community needs to grow up and stop chasing shiny things, because they're leaving huge numbers of people behind in their wake.

zamadatix 6y ago
Bikeshedding about the best approach to making it accessible aside I think we all agree there was no out of the box button with the exact functionality and styling the project needed. Many ways to build such a thing but all of which require someone actually making the software that way as part of the project scope. Difficult? Not really. Priority to implement from day 1 in this project? Well that's what started the conversation I suppose.
- jablan 6y ago
  How do you know what styling the project needed? What styling requires a button to stop being a button?
  - zamadatix 6y ago
    > How do you know what styling the project needed? I don't know what the project needed but I'll assume the author of the dialog knew and didn't purposefully pick a harder way to do it that intentionally spited others rather picked the easiest way to meet the styling goals. > What styling requires a button to stop being a button? None, did anyone ever claim you can't style a button to be whatever you want with more effort?
- danShumway 6y ago
  > I think we all agree there was no out of the box button with the exact functionality and styling the project needed We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-tricks.com/overriding-default-button-styles/ https://css-tricks.com/overriding-default-button-styles/ And it's a little bit debatable if you even want that style clear, because you should be using some of the stuff that buttons give you for free like graphical changes when the button is pressed, visual indication of focus, etc... That's all stuff that the final developer didn't even know they were missing from the final project. So it's not even really a question about "does the button look exactly like what I want." Many times, 'exactly what the dev wants' is explicitly the wrong choice to make. Most developers don't know every graphical effect and interaction that a button should have, and they shouldn't have to. The point of native components is to make this stuff easier; you don't have to think about every interaction and use case that every non-typical user might require. ---- In Firefox, I opened the dev tools, changed the div to a button, and added one line of CSS: border: none; And the button looks exactly the same as the div, except now it's visually focusable and accessible. Same is true in Chrome. And those are likely the only two rendering engines that the original developer cares about, it's not like IE11 is worth supporting for a WASM IDE. No bikeshedding needed here, I didn't even need to look up a button reset style.
  - zamadatix 6y ago
    I'm REALLY not looking for a debate on what technical changes are needed to make this accessible but I tried changing it to a button in the page (with border: none;) and immediately I notice it's larger and the underline hover effect is broken. It's also floating verically by a pixel. I'm sure there are other effects I haven't noticed immediately. This is exactly what I'm talking about on how it's not just free, there is work to making it work exactly the way the developer wanted it for the project. Maybe you think a button shouldn't look like that. Maybe you think a button should prioritize <list of things> before style. Maybe you just like to do something your own way. That's great, go ahead on your own project or hire this person for it. None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
    - danShumway 6y ago
      Are you setting it as an actual style under the `.button` class or are you attaching it to the element? I don't see any of the effects you're talking about. Size is the same, no pixel offset. If you change the div (not the selected SVG, but the div itself) into a button and then add `border: none` to the .button class, there should be no visual changes at all. I'm checking both the Firefox and Chrome dev tools, it's a 24 px high button with 8 pixels of padding. If there's some other visual change that goes along with that, I can't find it. ---- > None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility. There's another side to this though which is that it is genuinely helpful to tell people that there are very simple changes they could make to increase accessibility on a platform that we have a vested interest in making accessible. It's not helpful to be a jerk about it, but I'm not going to act like there's no right way to build something like this. I understand why someone might cut some corners on a quick project, or why they might not know everything there is to know about accessibility. I don't fault any developer over that. But there is a correct engineering answer to the question of how a button should be designed, and it actually does genuinely impact real people in the real world. Part of what we're doing here is trying to as much as possible without being jerks get across the idea that accessibility matters. We're trying to get across the point that it's not OK to have the web mostly not work for blind people and to say, "there aren't enough of them to care about." And especially in an area where fixing the problem is genuinely way less work than even having this conversation, and where fixing it would have zero downsides for the finished project, it is genuinely disheartening to see people putting forward the idea that literally any extra work at all means that accessibility has to be optional. How far are you going to take that? Is it unreasonable for me to ask people to spend an extra minute captioning the photos they upload to Twitter? There are categories of things where it reasonable to ask people to put in a tiny bit of extra work so that the web doesn't completely fail in its mission to be a universally accessible platform. We ask developers (even Open Source developers) to put in far more work over way more trivial, meaningless things than this. So yes, maybe it would have required an extra minute or two of work to style this as a button. And if the developer didn't know how to do that, fine, I'm not here to shame people for not knowing things, I have no ill will towards the developer for making that mistake. But I am here to shame people who say that one extra minute of work is too much for accessibility advocates to expect, and that asking developers to even think about accessibility is inherently unreasonable. We want developers to care about accessibility, we aren't neutral on that. We want developers to have a code of ethics and values that prioritizes equal access for everyone. That's part of the value ethos of the web as a platform. We spend so much time as advocates trying to dance around that issue and trying to make it easier for people to be 'accidentally' accessible when they build on the web, and to add tools and features that make accessibility the easier, natural engineering path. All of that is good, and we should keep doing that, and the accessible path here is the easier path, but on the other hand at some point we also have to be willing to say, "no, we expect you to genuinely care about blind people at least a little bit."

zamadatix 6y ago

Bikeshedding about the best approach to making it accessible aside I think we all agree there was no out of the box button with the exact functionality and styling the project needed. Many ways to build such a thing but all of which require someone actually making the software that way as part of the project scope. Difficult? Not really. Priority to implement from day 1 in this project? Well that's what started the conversation I suppose.

jablan 6y ago
How do you know what styling the project needed? What styling requires a button to stop being a button?
- zamadatix 6y ago
  > How do you know what styling the project needed? I don't know what the project needed but I'll assume the author of the dialog knew and didn't purposefully pick a harder way to do it that intentionally spited others rather picked the easiest way to meet the styling goals. > What styling requires a button to stop being a button? None, did anyone ever claim you can't style a button to be whatever you want with more effort?
danShumway 6y ago
> I think we all agree there was no out of the box button with the exact functionality and styling the project needed We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-tricks.com/overriding-default-button-styles/ https://css-tricks.com/overriding-default-button-styles/ And it's a little bit debatable if you even want that style clear, because you should be using some of the stuff that buttons give you for free like graphical changes when the button is pressed, visual indication of focus, etc... That's all stuff that the final developer didn't even know they were missing from the final project. So it's not even really a question about "does the button look exactly like what I want." Many times, 'exactly what the dev wants' is explicitly the wrong choice to make. Most developers don't know every graphical effect and interaction that a button should have, and they shouldn't have to. The point of native components is to make this stuff easier; you don't have to think about every interaction and use case that every non-typical user might require. ---- In Firefox, I opened the dev tools, changed the div to a button, and added one line of CSS: border: none; And the button looks exactly the same as the div, except now it's visually focusable and accessible. Same is true in Chrome. And those are likely the only two rendering engines that the original developer cares about, it's not like IE11 is worth supporting for a WASM IDE. No bikeshedding needed here, I didn't even need to look up a button reset style.
- zamadatix 6y ago
  I'm REALLY not looking for a debate on what technical changes are needed to make this accessible but I tried changing it to a button in the page (with border: none;) and immediately I notice it's larger and the underline hover effect is broken. It's also floating verically by a pixel. I'm sure there are other effects I haven't noticed immediately. This is exactly what I'm talking about on how it's not just free, there is work to making it work exactly the way the developer wanted it for the project. Maybe you think a button shouldn't look like that. Maybe you think a button should prioritize <list of things> before style. Maybe you just like to do something your own way. That's great, go ahead on your own project or hire this person for it. None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
  - danShumway 6y ago
    Are you setting it as an actual style under the `.button` class or are you attaching it to the element? I don't see any of the effects you're talking about. Size is the same, no pixel offset. If you change the div (not the selected SVG, but the div itself) into a button and then add `border: none` to the .button class, there should be no visual changes at all. I'm checking both the Firefox and Chrome dev tools, it's a 24 px high button with 8 pixels of padding. If there's some other visual change that goes along with that, I can't find it. ---- > None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility. There's another side to this though which is that it is genuinely helpful to tell people that there are very simple changes they could make to increase accessibility on a platform that we have a vested interest in making accessible. It's not helpful to be a jerk about it, but I'm not going to act like there's no right way to build something like this. I understand why someone might cut some corners on a quick project, or why they might not know everything there is to know about accessibility. I don't fault any developer over that. But there is a correct engineering answer to the question of how a button should be designed, and it actually does genuinely impact real people in the real world. Part of what we're doing here is trying to as much as possible without being jerks get across the idea that accessibility matters. We're trying to get across the point that it's not OK to have the web mostly not work for blind people and to say, "there aren't enough of them to care about." And especially in an area where fixing the problem is genuinely way less work than even having this conversation, and where fixing it would have zero downsides for the finished project, it is genuinely disheartening to see people putting forward the idea that literally any extra work at all means that accessibility has to be optional. How far are you going to take that? Is it unreasonable for me to ask people to spend an extra minute captioning the photos they upload to Twitter? There are categories of things where it reasonable to ask people to put in a tiny bit of extra work so that the web doesn't completely fail in its mission to be a universally accessible platform. We ask developers (even Open Source developers) to put in far more work over way more trivial, meaningless things than this. So yes, maybe it would have required an extra minute or two of work to style this as a button. And if the developer didn't know how to do that, fine, I'm not here to shame people for not knowing things, I have no ill will towards the developer for making that mistake. But I am here to shame people who say that one extra minute of work is too much for accessibility advocates to expect, and that asking developers to even think about accessibility is inherently unreasonable. We want developers to care about accessibility, we aren't neutral on that. We want developers to have a code of ethics and values that prioritizes equal access for everyone. That's part of the value ethos of the web as a platform. We spend so much time as advocates trying to dance around that issue and trying to make it easier for people to be 'accidentally' accessible when they build on the web, and to add tools and features that make accessibility the easier, natural engineering path. All of that is good, and we should keep doing that, and the accessible path here is the easier path, but on the other hand at some point we also have to be willing to say, "no, we expect you to genuinely care about blind people at least a little bit."