> Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project?
Yep as someone who's done a significant amount of front-end development ARIA and accessibility is more billable hours, more time involved into project, and more testing. When it's my own consulting I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Truth is most companies are pushing the cost of development down however they can, and to cater to the accessibility market you're sinking significant dev/testing time into doing it right. Also, you can't blame me in a capitalist society for dropping this on the floor when my customer/employer wants me to... in most situations the hours invested into accessibility will never turn around into profit.
The other problem is I do accessibility right. And most devs don't... I'll actually go through and do UIX experiences on-screen, then replicate it "blind" using a screen reader. This testing/tuning takes real time. Like - I can go through and do best practices with ARIA tags, well thought out HTML5, etc and still it's a total cluster once you actually use the application.
It very much may not be "ignorance/difficult" - looking at what this dev has accomplished with this editor I'm going to give them the benefit of the doubt and say it was just extra time for a tiny fraction of their audience that they haven't invested yet. Harsh reality is they may not have that budget of time to go the extra steps for something as complex as this.
> I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Take note, the takeaway from this comment is that if you're building a platform for applications and you want to make it accessible, it has to be required. You can't give engineers the choice or they won't do it. They will not prioritize equal access unless either the law or the technology literally forces them to. This kind of stuff is how you get regulated.
This is also why I don't have a ton of sympathy for the people who want to get rid of HTML and use exclusively lower level APIs. They'll tell you they can replicate accessibility features, but they're not going to. They're going to open up the floodgate for interfaces that can't be used with a keyboard. Like, I'm not seriously suggesting this, but maybe divs in HTML shouldn't be clickable at all. Maybe you should be forced to use a button. Maybe the escape hatches that allow people to ignore semantic markup should go away.
I want to live in a world where I can trust developers when they say that the web is for everyone and that equal access is important, and I want to trust them to make educated decisions about what is and isn't possible to make accessible for each project. But if we can't even get people to use buttons instead of divs, if even that turns into some kind of controversy... I don't know, maybe developers shouldn't get to make that choice, maybe the web should force you to use buttons.
The whole point of the web is that it's a universal platform, as much as possible we should be striving to make it universally accessible.
> The other problem is I do accessibility right
We're not talking about something like adding professional captions to every single video you produce or making sure that there are shortcuts to quick-navigate through menus, we're talking about building buttons using the element named "button".
Accessibility isn't binary, we don't have to decide to either do professional testing or to render everything to canvas. It really doesn't take firing up a screenreader to know that a clickable div with no aria roles is not accessible, you don't have to do advanced testing for that.
I'm not going to jump on the shame train for the original author, not everyone knows this stuff and I don't blame the author for making a mistake. I don't expect every web developer to know everything, and shaming people over accidentally breaking accessibility isn't helpful for the cause. Instead we should focus on education and positive reinforcement. We don't want new developers to be scared of accessibility, we want them to feel like we're here to help.
But outside of the original developer, I am absolutely going to jump on the shame train for everyone who's talking about very basic web accessibility features like they're some kind of complicated tradeoff. They're not. Using a button is not hard.
>
I want to live in a world where I can trust developers when they say that the web is for everyone and that equal access is important, and I want to trust them to make educated decisions about what is and isn't possible to make accessible for each project. But if we can't even get people to use buttons instead of divs, if even that turns into some kind of controversy... I don't know, maybe developers shouldn't get to make that choice, maybe the web should force you to use buttons.
Most developers only get to make that choice as long as visibility over their work is shitty enough that any time spent on accessibility is lost in the noise.
The button stuff is one of the few things that could (and should) just be done by default, because it doesn't take any extra effort like a lot of accessibility work. But then again, most devs are working in environments where whatever they would just make a plain old button gets loved to death by some design genius with nothing better to do that week and "signed off on" by 15 people before the dev even hears about it. Then they're making a quick decision between throwing accessibility under the bus (and suffering absolutely zero consequences for it) or pissing off literally everyone that has anything to do with their next round of performance reviews.
Right, which is why we need to somewhat entertain the idea that accessibility shouldn't be optional.
In the business environment you're talking about, I'm generally not in favor of legislating things, but maybe that's a requirement here. My point is that assuming what folkhack says is true, then the "we'll just educate people" idea might just not be feasible -- maybe it just straight up requires laws that force businesses to care.
At least for websites in general we can do things outside of the law that force people's hands. Google can deprioritize search results for pages that are inaccessible, but that won't really affect web apps. Maybe there are non-legislative technological penalties we could impose there as well; if there are certain things that only buttons can do, or if browsers start identifying pages/apps that are inaccessible and displaying warnings on them, or locking certain features.
SSL didn't really get solved until browsers started putting a big scary warning next to the URL bar that said the page was insecure. All the education and tooling was helpful, but it wasn't enough to make businesses care until their customers started asking them why Chrome/Firefox was saying that their app was insecure. It's tricky. I don't want the accessibility community to be the villain here, but it does kind of sound like commercial businesses need to be dragged into an accessible world even if they're kicking and screaming about it.
Yep as someone who's done a significant amount of front-end development ARIA and accessibility is more billable hours, more time involved into project, and more testing. When it's my own consulting I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Truth is most companies are pushing the cost of development down however they can, and to cater to the accessibility market you're sinking significant dev/testing time into doing it right. Also, you can't blame me in a capitalist society for dropping this on the floor when my customer/employer wants me to... in most situations the hours invested into accessibility will never turn around into profit.
The other problem is I do accessibility right. And most devs don't... I'll actually go through and do UIX experiences on-screen, then replicate it "blind" using a screen reader. This testing/tuning takes real time. Like - I can go through and do best practices with ARIA tags, well thought out HTML5, etc and still it's a total cluster once you actually use the application.
It very much may not be "ignorance/difficult" - looking at what this dev has accomplished with this editor I'm going to give them the benefit of the doubt and say it was just extra time for a tiny fraction of their audience that they haven't invested yet. Harsh reality is they may not have that budget of time to go the extra steps for something as complex as this.