I spent a while working at an accessibility company, and while I was there, worked on two separate things:
1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.)
2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on.
Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true.
Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.
IMO, if you start off with sane good practices, it's really not that difficult to work for a11y in web. Just adhering to good markup and keyboard-first navigation will get you most of the way "there", especially if the designers are aware of their constraints and designing with a11y in mind.
But reworking stuff that isn't already working around a11y is a massive pain in the ass.
So I "get" it, and I've built a lot of stuff that doens't serve every population as well as it could have if I had been more informed. But at this point, for new work it doesn't feel like much of a burden at all, any more than using git or linters or whatever other stuff we do because it's a helpful practice.
1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.)
2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on.
Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true.
Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.