5 ms·

Not everything has to be accessible. 100% blindness isn't that common. And even if it was, there's nothing wrong with making apps for people with good vision.

mwcampbell 8y ago
A blind person can lose their job because an application that's required for the job is inaccessible, even though the job function ought to be perfectly accessible (i.e. isn't inherently visual). That happened to an acquaintance of mine. May it never happen again.
- fastball 8y ago
  How is that the application creator's fault? That's a problem with the employer, not the application. Applications do not need to cater to every edge case of humanity.
  - mwcampbell 8y ago
    Yes, the employer is at fault in that case. But the application creator is as well, because they erected the barrier of an inaccessible app.
    - vinceguidry 8y ago
      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. The only reason not to is greed.
      - LoSboccacc 8y ago
        > The only reason not to is greed while accessibility is important this extremisation is a little rich under a post of a literally free tool.
        vinceguidry 8y ago
        You're ignoring the preceding qualifiers. A tool that can be used for work, and a profit motive.
        LoSboccacc 8y ago
        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.
        HeWhoLurksLate 8y ago
        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.
      - yjftsjthsd-h 8y ago
        > the profit motive should be there > The only reason not to is greed. This seems contradictory? If there's a profit to be had, then greed would demand that it be taken.
    - fastball 8y ago
      They "erected" nothing. 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. You really think the second example is better?
      - mwcampbell 8y ago
        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.
        HeWhoLurksLate 8y ago
        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.

mwcampbell 8y ago

A blind person can lose their job because an application that's required for the job is inaccessible, even though the job function ought to be perfectly accessible (i.e. isn't inherently visual). That happened to an acquaintance of mine. May it never happen again.

fastball 8y ago
How is that the application creator's fault? That's a problem with the employer, not the application. Applications do not need to cater to every edge case of humanity.
- mwcampbell 8y ago
  Yes, the employer is at fault in that case. But the application creator is as well, because they erected the barrier of an inaccessible app.
  - vinceguidry 8y ago
    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. The only reason not to is greed.
    - LoSboccacc 8y ago
      > The only reason not to is greed while accessibility is important this extremisation is a little rich under a post of a literally free tool.
      - vinceguidry 8y ago
        You're ignoring the preceding qualifiers. A tool that can be used for work, and a profit motive.
        LoSboccacc 8y ago
        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.
        HeWhoLurksLate 8y ago
        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.
    - yjftsjthsd-h 8y ago
      > the profit motive should be there > The only reason not to is greed. This seems contradictory? If there's a profit to be had, then greed would demand that it be taken.
  - fastball 8y ago
    They "erected" nothing. 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. You really think the second example is better?
    - mwcampbell 8y ago
      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.
      - HeWhoLurksLate 8y ago
        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.