One of the weird parts I find about accessibility is that it tends to be considered as ‘something the developers do’. That we can solve accessibility just through technical means, and generally just by playing around with the user interface. In organization after organization I see accessibility as something the tech org has to champion to get time to deliver on, so it gets seen as an ‘extra cost’ of developing a feature. But the fact is that some features, as requested, are really hard to deliver in an accessible way - but if you thought about what you wanted to deliver from an accessible angle in the first place you might find there’s a way to solve the problem that is intrinsically more accessible.

In general not enough attention is paid to just flat out whether an entire business process is accessible. Or perhaps more - how you can adjust your business, your offering, or your process in order to make it possible for more people to access it, or to be employed by you in delivering it.

If you treat accessibility as a box checking exercise done by web and app devs you can end up worrying about making the driver portal of your ride sharing app work for a blind user, rather than thinking about what features are needed to make it possible for a person in a wheelchair to hire a rideshare that can accommodate them.

Accessibility doesn’t begin and end at screenreader support and text contrast levels. But if you leave it up to developers to do then that may be all you’re going to be able to get.

Agree with this. As much shade as I tend to throw at engineers for not considering the consequences of our actions, finance, sales, and marketing are absolutely different beasts here, and you're right that it often does wind up being engineering that's trying to push for these viewpoints.

The baby stroller's a classic - the number of people I know who've suddenly gained an appreciation for the ADA after having kids...