> Plus, its not that hard to do correctly, so the “we’re a startup on a critical burn rate” stops working as an excuse rather early It's not a question of it b

> Plus, its not that hard to do correctly, so the “we’re a startup on a critical burn rate” stops working as an excuse rather early It's not a question of it being too hard or easy, but as always, a question of priorities. Say you can either build feature A which is expected to open up the product to be used by 1% more users, as people been asking for that feature. Or you can build feature B, which enables motionsick people to use your app without getting sick from your wasteful animations. This will help 0.001% of your current users, when you have 10,000 users in total lets say. Not saying it's right or wrong, but I understand why people (managers/owners) make the choice to do feature A instead of feature B, especially in a startup-context where it might be the (imaginary or not) choice between surviving or not. I'm personally in the camp of thinking about accessibility as part of all the work done, but it's not exactly the mainstream workflow.