Accessibility is not something that exists until a developer nerfs it. Accessibility takes time and effort to implement.
Take two examples:
* I release an app without much accessibility support on April 5th. Immediately, 90-95% of my prospective customer base can use the app. 5-10% cannot. Over the next few months, I improve my app's accessibility and release the new version on July 5th. Now, 99% of potential customers can use it. In the interim period of three whole months though, the vast majority of potentials were able to use my product.
* I think an app is not worth releasing until it has comprehensive accessibility support. It takes me a couple extra months than it would've without it, but eventually I release my product on July 5th. Yay. 99% of my potential customers can use it at the time of first release.
I actually do think the second scenario is better. Some people will lack a convenience in the intervening three months (and remember that's a very optimistic case; it could be4 much longer). But at least a person with a disability won't lose their job because it now requires an app that they can't use.
Ok, now give your reply when the 'app' is critical to saving lives. Each hour it isn't available costs, let's say, 1 infant their life who could otherwise have been saved, per 1000 app users.
The point of the exercise being that you seem to be dismissing the fact that there are actual bad consequences to the 'must be 100% accessible upon first release' principle, simply because a person for whom accommodation is required now has a job.
What I don't see in your argument is some sort of equitable discussion of who bears what costs, and how that equity is fairly determined.
> Some people will lack a convenience in the intervening three months
> lose their job because it now requires an app that they can't use.
So is it a convenience or essential for the job? If it is a convenience, then it isn't essential. If it is essential, you're denying it to the larger group in the interim.
I think the idea is: the new app is a convenience to a job that existed before the app. The company that uses it then decides to make it essential to that job.
So you think it's better for everyone to have less convenience so that it is literally impossible to discriminate, instead of just telling employers "don't discriminate"?
Maybe we should just go ahead and gouge everyone's eyes out to really level the playing field...
If you've taken calculus, you'll understand the idea of area under the curve- the number of people using your app will likely go up over time, and it takes time to accrue customers (the area under the curve of the rate of customers). One thing that you should think about is that it takes time for products to gain momentum, and as a product gains momentum, it generates revenue. As such, it might make sense to ship your code without much accessibility support and add it in the ensuing months. If you can be available to even 50% of potential customers three months before the first scenario, by only releasing for people using the OS you develop on, and then you go cross-platform in three, (making your population ~90%) and then add accessibility in the sixth month, it would still make sense from a business point of view to do so.
Keep in mind that things take time to develop a userbase, and that large companies really like things to have an established userbase and support before they get on board. For instance, one of the major reasons that the Raspberry Pi Foundation has seen so much success, even though they aren't the fastest or the cheapest, is because they have a large community support network and support their stuff well.
As such, as long as I (and / or management) are committed to implementing solely-accessibility related features in the near future, I would take the first option, and release as soon as I could.
I share your sentiments. Anybody building a tool that could conceivably be used for work purposes has a moral impetus to treat accessibility as a first-class citizen. The standards are there, the profit motive should be there and thus the resources should be there.
that's a non sequitur. a free tool doesn't have a profit motive and a company using the tool for profit doesn't attach a profit motive to the tool itself.
But they have an interest in their "free" tools being around the next day, don't they? Otherwise they have to either do it the "old way" or find a replacement, both of which cost time. At $100,000 a year per 40-hour-work-week developer, a team of 5 developers costs $240 an hour. That's a lot to lose because your tools disappeared. Analogous to physical work, consider what getting a new tool that's slightly different does to your muscle memory- there's an inherent value in having long-lasting tools, even if they're free.
