3 ms·

15+ years ago, I worked for an Australian university. We had a project to migrate to a new student email system – we were going from Novell NIMS (hosted on NetW

15+ years ago, I worked for an Australian university. We had a project to migrate to a new student email system – we were going from Novell NIMS (hosted on NetWare) to Sun/iPlanet/JES Messaging (on Solaris). We asked our disability services office to review the webmail's accessibility. The manager of that office was a blind woman, who was both a staff member and a student, so she had her own personal student account. She told us she couldn't use Sun's webmail, it wouldn't work at all with her screen reader. We complained to Sun, their response was "we know, wait for the next major version". What did we do? We offered her a shell account on a Solaris box with Pine, and told her that we'd offer the same to any vision-impaired students or staff members who requested it. And she was happy with that solution. IANAL a lawyer, but from my understanding of disability discrimination law (which is different in different countries anyway), you are legally obliged to offer "reasonable accomodations" – which doesn't have to necessarily be by making the application accessible, it could be offering access to an alternative application instead. Also, you are only obliged to provide accessibility if a disabled user asks for it, which assumes you have a user with a relevant disability – if your application is sufficiently niche, that might never happen. Suppose you build an internal GUI for SREs to use. Do you need to make that accessible for the vision impaired? Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.

MrJohz 3y ago
> Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation. I don't completely disagree with you, I think accessibility is often a spectrum, and it's good to be thinking in terms of what your specific accessibility needs are, rather than just going for a scattergun approach. That said, I have some problems with this example. Firstly, a lot of features end up in the "accessibility" bin that are more broadly useful (the "cut curb effect"). Your SREs might be fully sighted and mobile, but they will probably still appreciate being able to drive the software fully by keyboard. And even from a development perspective, I've found having correct aria roles etc can often be useful for end-to-end testing because it allows you to be more semantic with the tests ("click on the thing with a button role with the text 'submit'" rather than "click on the element with the ID '...'"). Secondly, we often see accessibility in terms of the extreme cases ("you are blind, you have unlocked the accessibility treatment now"), but accessibility is more broad than that. If you're working late at night in a dark room, or trying to do something on a small laptop screen, or you were out climbing and now your wrists ache, you might still appreciate accessibility features - zooming, keyboard navigation, accessible themes etc. Getting this stuff right helps everyone. Finally, retrofitting accessibility is often a nightmare to actually implement, because (a) it's hard to notice what's not working unless you go through everything with a fine-toothed comb, and (b) if you don't have at least some accessibility plans to start with, you might have dug yourself into a corner that you can't get out of. For example, if your gui framework has no accessibility support, and someone blind starts in a month's time, what are you going to do? Rewrite the whole application for them?
- TeMPOraL 3y ago
  Yes, accessibility is all that too. But those things are what the vendors usually do not want to do. As in, actively, because that gives agency to the user, and would defeat whatever abusive business trickery they built the software to inflict on people in the first place. We talk about accessibility in terms of extremes, because those extremes are where we have legal support that companies can't ignore. The vendors don't want to cut the curb, they want to replace it with a fence and a toll gate. Talking about wheelchairs and strollers lets us prevent the fences, and the toll gates. If they figure they'll skip the curb too, every user wins, but this won't happen without prioritizing wheelchairs, and won't happen if we emphasize regular people too much. Or, in short, accessibility is the only weapon we have to fight dark patterns and maybe get some ergonomics for everyone.

MrJohz 3y ago

> Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation. I don't completely disagree with you, I think accessibility is often a spectrum, and it's good to be thinking in terms of what your specific accessibility needs are, rather than just going for a scattergun approach. That said, I have some problems with this example. Firstly, a lot of features end up in the "accessibility" bin that are more broadly useful (the "cut curb effect"). Your SREs might be fully sighted and mobile, but they will probably still appreciate being able to drive the software fully by keyboard. And even from a development perspective, I've found having correct aria roles etc can often be useful for end-to-end testing because it allows you to be more semantic with the tests ("click on the thing with a button role with the text 'submit'" rather than "click on the element with the ID '...'"). Secondly, we often see accessibility in terms of the extreme cases ("you are blind, you have unlocked the accessibility treatment now"), but accessibility is more broad than that. If you're working late at night in a dark room, or trying to do something on a small laptop screen, or you were out climbing and now your wrists ache, you might still appreciate accessibility features - zooming, keyboard navigation, accessible themes etc. Getting this stuff right helps everyone. Finally, retrofitting accessibility is often a nightmare to actually implement, because (a) it's hard to notice what's not working unless you go through everything with a fine-toothed comb, and (b) if you don't have at least some accessibility plans to start with, you might have dug yourself into a corner that you can't get out of. For example, if your gui framework has no accessibility support, and someone blind starts in a month's time, what are you going to do? Rewrite the whole application for them?

TeMPOraL 3y ago
Yes, accessibility is all that too. But those things are what the vendors usually do not want to do. As in, actively, because that gives agency to the user, and would defeat whatever abusive business trickery they built the software to inflict on people in the first place. We talk about accessibility in terms of extremes, because those extremes are where we have legal support that companies can't ignore. The vendors don't want to cut the curb, they want to replace it with a fence and a toll gate. Talking about wheelchairs and strollers lets us prevent the fences, and the toll gates. If they figure they'll skip the curb too, every user wins, but this won't happen without prioritizing wheelchairs, and won't happen if we emphasize regular people too much. Or, in short, accessibility is the only weapon we have to fight dark patterns and maybe get some ergonomics for everyone.