Could those critics have been nicer? Sure, that would have bruised my ego less. But disabled people and accessibility advocates don’t owe it to me or to anyone to be nice.
I think it’s important to distinguish between “not nice” and “cruel”. When I was on Twitter, I’d regularly see this:
A person does an accessibility fail, like leaving out alt-text from the images.
Someone calls them out for the fail.
Dozens of other people pile on the callout, send angry DMs, harass them in unrelated tweets, etc.
I’ve lived parts of my life with people who used topics like accessibility as an opportunity to be cruel and vindictive. So while it’s important to not have an ego about it, and accept that people are frustrated for legitimate reasons, not everybody shaming you want you to Do Better. Some just want to be mean.
not everybody shaming you want you to Do Better. Some just want to be mean.
oh this is quite generous. in the general case (i can’t speak to accessibility shaming in particular but i doubt it’s an exception), i’d argue the overwhelming majority of morality police of any stripe, especially on twitter, simply enjoy seeing the faces of the pilloried covered in rotten tomato. a sadism ticket with a free righteousness stamp – intoxicating!
there are some, a small minority, who genuinely care, and because they want to be effective they are generally nice about things.
I don’t know what is it like to need assistive technologies like this. I don’t think the people who do need these owe anyone anything. And I certainly don’t think they aren’t frustrated by everything.
But I always believed that it’s better to be nice than mean. Not because other people deserve it or something, but simply because for me, being negative brings more negativity to me, basically I’m making myself even less happy then I was.
I know it’s not the same for everybody, but what I have experienced, what I have observed, and what I’ve learned from psychology and other areas, all that tells me it’s gonna work for majority of people. Maybe not overwhelming majority, but a majority.
Now, maybe being cruel here isn’t about how the cruel guy feels. Maybe it’s just an act, to get someone to change something. Maybe something else entirely.
But I definitely think that being nice is better then being cruel most of the time. Especially when you want other people to change something that concerns you.
I’m ready to blanket accessibility shame the majority of reusable JavaScript library components.
If you release JavaScript widgets for people to use - navigation menus, carousels, button libraries etc - and you don’t include explicit documentation about how you have made those things accessible for screen readers, you should fix that.
Most of the time when I go to find a new front-end component this documentation is very clearly missing. Usually that means that they have not made their stuff accessible, which is bad. It can also mean that they DID make their stuff accessible, but then didn’t take the time to explain that - a big problem for people like myself who treat accessibility as a key decision-making factor.
Part of my frustration here is that I feel like ~10 years ago we had a pretty great thing going on with web accessibility: we knew how to built semantic, accessible pages using regular HTML. Then the SPA trend came along and threw most of that out of the window. We’re still struggling to figure that out.
I’ve been following Tailwind UI and Alpine components and I think they’re both trying to do the right thing. It is very hard though. Every time you think you’ve gotten it, someone says “oh no, aria-X is worse than useless in browser Y and now someone’s computer is just making a high pitched noise until their ears start bleeding.” It has to get simpler someday.
Yeah, I don’t find the ARIA stuff and those tools that scan for attributes etc very convincing.
What I really want to see is evidence of screenreader testing. My absolute dream is a UI component library that includes video (or audio) recordngs of screenreader sessions with their components - but I’ve never seen anyone even attempt that yet.
Agreed that if you make a tool and put it out into the world, you have a responsibility to make sure that you’re not unintentionally discriminating against people. I do want to quibble with this, though:
Part of my frustration here is that I feel like ~10 years ago we had a pretty great thing going on with web accessibility: we knew how to built semantic, accessible pages using regular HTML. Then the SPA trend came along and threw most of that out of the window. We’re still struggling to figure that out.
A big part of the problem is that apps got more complicated and the platform didn’t keep up. We didn’t get support in all major browsers for native modals (via the dialog element) until last year. We’re still waiting on popovers and selectmenu. There aren’t even any plans that I know for things like dropdown menus or toasts or tabs.
So while I share your scorn for developers of inaccessible JS component libraries, I also think it should be an extremely high priority to provide those tools at the browser level. I shouldn’t even need to install a library in the first place to get an accessible dropdown menu. Sure, developing standards is complicated, but if there were ever an important cow path to pave it’s this one!
Anyway, if anyone is looking for an accessible component library, I’ve had a wonderful time using Shoelace. (I’ve also heard good things about Adobe Spectrum, although I haven’t tried it out myself.) They both use web components, so you can use them on static webpages and also with any JavaScript framework.
I now assume it’s saltiness built up from years of exhaustion
I feel like its half that, half: It feels like people are hurting themselves with some of these things, e.g. almost no one likes super-low contrast for text, tiny buttons, back button not working, mystery meat navigation, et al. It feels like people are hurting themselves to spite others. (of course, not the actual case).
It helps me to remember that being healthy and “able” is a temporary state.
I sort of wish there was more meat to this article.
I think it’s important to distinguish between “not nice” and “cruel”. When I was on Twitter, I’d regularly see this:
I’ve lived parts of my life with people who used topics like accessibility as an opportunity to be cruel and vindictive. So while it’s important to not have an ego about it, and accept that people are frustrated for legitimate reasons, not everybody shaming you want you to Do Better. Some just want to be mean.
oh this is quite generous. in the general case (i can’t speak to accessibility shaming in particular but i doubt it’s an exception), i’d argue the overwhelming majority of morality police of any stripe, especially on twitter, simply enjoy seeing the faces of the pilloried covered in rotten tomato. a sadism ticket with a free righteousness stamp – intoxicating!
there are some, a small minority, who genuinely care, and because they want to be effective they are generally nice about things.
I don’t know what is it like to need assistive technologies like this. I don’t think the people who do need these owe anyone anything. And I certainly don’t think they aren’t frustrated by everything.
But I always believed that it’s better to be nice than mean. Not because other people deserve it or something, but simply because for me, being negative brings more negativity to me, basically I’m making myself even less happy then I was.
I know it’s not the same for everybody, but what I have experienced, what I have observed, and what I’ve learned from psychology and other areas, all that tells me it’s gonna work for majority of people. Maybe not overwhelming majority, but a majority.
Now, maybe being cruel here isn’t about how the cruel guy feels. Maybe it’s just an act, to get someone to change something. Maybe something else entirely.
But I definitely think that being nice is better then being cruel most of the time. Especially when you want other people to change something that concerns you.
I’m ready to blanket accessibility shame the majority of reusable JavaScript library components.
If you release JavaScript widgets for people to use - navigation menus, carousels, button libraries etc - and you don’t include explicit documentation about how you have made those things accessible for screen readers, you should fix that.
Most of the time when I go to find a new front-end component this documentation is very clearly missing. Usually that means that they have not made their stuff accessible, which is bad. It can also mean that they DID make their stuff accessible, but then didn’t take the time to explain that - a big problem for people like myself who treat accessibility as a key decision-making factor.
Part of my frustration here is that I feel like ~10 years ago we had a pretty great thing going on with web accessibility: we knew how to built semantic, accessible pages using regular HTML. Then the SPA trend came along and threw most of that out of the window. We’re still struggling to figure that out.
I’ve been following Tailwind UI and Alpine components and I think they’re both trying to do the right thing. It is very hard though. Every time you think you’ve gotten it, someone says “oh no, aria-X is worse than useless in browser Y and now someone’s computer is just making a high pitched noise until their ears start bleeding.” It has to get simpler someday.
Yeah, I don’t find the ARIA stuff and those tools that scan for attributes etc very convincing.
What I really want to see is evidence of screenreader testing. My absolute dream is a UI component library that includes video (or audio) recordngs of screenreader sessions with their components - but I’ve never seen anyone even attempt that yet.
Agreed that if you make a tool and put it out into the world, you have a responsibility to make sure that you’re not unintentionally discriminating against people. I do want to quibble with this, though:
A big part of the problem is that apps got more complicated and the platform didn’t keep up. We didn’t get support in all major browsers for native modals (via the dialog element) until last year. We’re still waiting on popovers and selectmenu. There aren’t even any plans that I know for things like dropdown menus or toasts or tabs.
So while I share your scorn for developers of inaccessible JS component libraries, I also think it should be an extremely high priority to provide those tools at the browser level. I shouldn’t even need to install a library in the first place to get an accessible dropdown menu. Sure, developing standards is complicated, but if there were ever an important cow path to pave it’s this one!
Anyway, if anyone is looking for an accessible component library, I’ve had a wonderful time using Shoelace. (I’ve also heard good things about Adobe Spectrum, although I haven’t tried it out myself.) They both use web components, so you can use them on static webpages and also with any JavaScript framework.
I feel like its half that, half: It feels like people are hurting themselves with some of these things, e.g. almost no one likes super-low contrast for text, tiny buttons, back button not working, mystery meat navigation, et al. It feels like people are hurting themselves to spite others. (of course, not the actual case).