8 ms·

Users with accessibility needs deserve to be able to use software as much as any of the rest of us do, and we should pride ourselves in making time to address t

Users with accessibility needs deserve to be able to use software as much as any of the rest of us do, and we should pride ourselves in making time to address their needs. Try reading your comment from the perspective of someone who is unable to use this software because of the choices you've made. Someday, perhaps sooner than you think, you might find yourself in their shoes. In this case, mwcampbell refers to a specific problem which is entirely avoidable and endemic of a flagrant disregard for the needs of accessibility - it would have been EASIER to make it accessible in Matt's example.

zamadatix 6y ago
I agree that if we make something we intend for others to use it should aim to be accessible to others. Nobody here is saying others shouldn't be able to use software the problem is software is never complete and for a project like this getting the thing working may reasonably happen before you add ARIA attributes without the cause being enmity to others. I might be missing something, how would it have been easier to make by adding additional ARIA markup to the UI?
- pegasus 6y ago
  They could have just used off-the-shelf components for the first iteration.
  - zamadatix 6y ago
    Using the builtin browser button element isn't without other things to then fix in the software either, "(getting anything to automagically work in UI is a pain still)". Would it have been accessible though, sure. But I'm going to assume that the developer didn't spin a wheel and decide to add React to the project rather it was intentionally chosen for some reason. Similarly in their React button version they could have added ARIA attributes. The problem statement was never "is there a way it could have been made accessible" it's that there isn't going to be a fullproof automagical way to make it accessible without having to do additional work in the project be it styling the default button or changing it's handlers or adding accessibility to a custom button. i.e. it's not a matter of technical exercise for how it could have been accessible it's being realistic about why it wasn't.
- xingyzt 6y ago
  The clickable divs should be focusable and have the aria button role. <div tabindex="0" role="button">...</div>
  - zamadatix 6y ago
    Agreed they should to have accessibility support.
  - chrismorgan 6y ago
    This is necessary but insufficient. If you use role=button, it needs to behave like a button, which means that Space and Enter must also activate it. Things to read: https://www.w3.org/TR/wai-aria-practices/#read_me_first https://www.w3.org/TR/wai-aria-practices/#read_me_first https://www.w3.org/TR/wai-aria-practices/#button https://www.w3.org/TR/wai-aria-practices/#button
- ddevault 6y ago
  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 agree that if we make something we intend for others to use it should aim to be accessible to others. Nobody here is saying others shouldn't be able to use software the problem is software is never complete and for a project like this getting the thing working may reasonably happen before you add ARIA attributes without the cause being enmity to others. I might be missing something, how would it have been easier to make by adding additional ARIA markup to the UI?

pegasus 6y ago
They could have just used off-the-shelf components for the first iteration.
- zamadatix 6y ago
  Using the builtin browser button element isn't without other things to then fix in the software either, "(getting anything to automagically work in UI is a pain still)". Would it have been accessible though, sure. But I'm going to assume that the developer didn't spin a wheel and decide to add React to the project rather it was intentionally chosen for some reason. Similarly in their React button version they could have added ARIA attributes. The problem statement was never "is there a way it could have been made accessible" it's that there isn't going to be a fullproof automagical way to make it accessible without having to do additional work in the project be it styling the default button or changing it's handlers or adding accessibility to a custom button. i.e. it's not a matter of technical exercise for how it could have been accessible it's being realistic about why it wasn't.
xingyzt 6y ago
The clickable divs should be focusable and have the aria button role. <div tabindex="0" role="button">...</div>
- zamadatix 6y ago
  Agreed they should to have accessibility support.
- chrismorgan 6y ago
  This is necessary but insufficient. If you use role=button, it needs to behave like a button, which means that Space and Enter must also activate it. Things to read: https://www.w3.org/TR/wai-aria-practices/#read_me_first https://www.w3.org/TR/wai-aria-practices/#read_me_first https://www.w3.org/TR/wai-aria-practices/#button https://www.w3.org/TR/wai-aria-practices/#button
ddevault 6y ago
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.