I would never agree with this statement of the author: "You won’t stop until everybody is using your app." Why ? All the apps I ever build (or participate in their development) where targeted to the fit the most, without sacrificing the business requirements or other important/critical aspects of the app. Otherwise will end-up with an unusable product.
I don't know - I'm always amused at how companies will try all sorts of growth hacks to eke out an extra 1% of DAU or whatever, but won't prioritise building products for human beings.
Companies do all sorts of (IMO insane) things to their apps that reduce their reach. Ignoring accessibility is just one of them.
I remember when I was in the app-writing business, and our devs would be constantly trying to bump up the minimum OS version supported. “See here, it says that only 10% of customer devices are on OS version 10.1 and below. We must bump our minimum version to 10.2 because us developers are tired of supporting this old shit and legacy code paths!”
This seems to me to be a lot like a salesman simply hanging up on 1 out of 10 of their potential customers. Makes no sense to me, but the version bumpers seem to be winning. The number of apps that no longer support my iPhone 7 is growing and growing…
I'd imagine this is likely true. The other thing to consider, is that apps don't necessarily need to be updated. Many can continue to work on old versions forever if the developer takes care with planning.
I'm thinking specifically of a 3rd party camera app, or maybe one of these modern 3D mapping apps that uses LIDAR to model a room. These apps can (and should!) continue to work on the hardware they were developed for, even if the author bumps the minimum version past what is supported. If the app author builds in reliances on a web api that expects an up-to-date companion app, that was/is shortsighted and should be discouraged.
Except companies that produce apps and games for small kids. They would go out of their way to support old devices released more than 10 years ago because their customers (small kids) mostly use devices handed down from their parents.
> "See here, it says that only 10% of customer devices are on OS version 10.1 and below. We must bump our minimum version to 10.2 because us developers are tired of supporting this old shit and legacy code paths!"
This makes sense if that 10% are costing more money than they generate, which seems especially likely since people that are frugal enough to (for example) hang onto an iPhone 7 are also unlikely to spend much on other frivolous purchases.
Supporting those older devices can range from supporting multiple code paths due to different APIs, or fallbacks for missing HW performance and/or features. All of that adds up in terms of developer time, build/infra cost, etc.
Do you have any real estimate of what not breaking old devices cost? With so much effort being wasted on site/app redesigns that degrade user experience (and cut off old devices in the process) it's also easy to imagine that it's not about the costs
Moreover, the target "audience" of an app is always specified before the design phase, in the Business Requirements Document and such and it's a defining element for the development. I've read/wrote hundreds of such documents in my career, yet I've never seen one that sets its target audience as 'everybody'.
You should see how ADA requirements are practically impossible or completely break design. The high contrast of font to background requirement is so extreme that most major sites and even ADA related sites fail. Things like alt text is so time consuming it would be incredibly expensive to label all the images. Facebook has long resorted to using AI descriptions.
Really it shouldn't be up to the developer it should be up to the disabled person to buy tools. Just like someone may need to buy a wheelchair to move around, they should have to buy a specialty browser that handles their limited visibility needs or brail tool interface.
> “Really it shouldn't be up to the developer it should be up to the disabled person to buy tools. Just like someone may need to buy a wheelchair to move around, they should have to buy a specialty browser that handles their limited visibility needs or brail tool interface.”
No, that’s the wrong analogy. The ADA is there to ensure that people with wheelchairs can find a barrier-free entrance to a building, and a curb cut at an intersection.
It should be on us, the developers, to ensure our apps work with the tools of the trade to enable people with limitations. So, our apps should be usable by screen readers. The screen reader is the analogue to the wheelchair here.
This is one of the great things about HTML. Even ignorant / lazy / time-constrained developers are likely to output something that sorta works, just since they’re using divs and imgs and whatnot.
And the bar is so low! Adding accessibility labels takes not much effort at all. And, as an added bonus, accessible apps are easier to test, since testing frameworks like Playwright can hook into accessibility info directly to validate assertions.
> find a barrier-free entrance to a building, and a curb cut at an intersection
I disagree with this too. It's a social nicety but shouldn't be a requirement.
> It should be on us, the developers, to ensure our apps work with the tools of the trade to enable people with limitations
Why? I argue it should be on the disabled person.
> The bar is so low.
Not really. There are groups of lowers running around looking for people to shake down for ADA misses. To really protect yourself it takes a lot of time.
> high contrast of font to background requirement is so extreme
Extreme? The WCAG standard for text most organizations use (Level AA) is 4.5:1 with 1:1 being black-on-black and 21:1 being black-on-white (or vice versa). The higher standard (Level AAA) is only 7:1. Most people wouldn't want to read your content if everything was 7:1 or lower.
> Facebook has long resorted to using AI descriptions
Facebook didn't upload those images, their users did, Facebook isn't responsible for them having good text alternatives.
> Just like someone may need to buy a wheelchair to move around
To go along with your poor analogy, blind people have "wheelchair" equivalents, called screen readers. They're useless if don't build "ramps" that meet established building standards, websites and apps that follow established standards.
> Things like alt text is so time consuming it would be incredibly expensive to label all the images. Facebook has long resorted to using AI descriptions.
> Really it shouldn't be up to the developer it should be up to the disabled person to buy tools. Just like someone may need to buy a wheelchair to move around, they should have to buy a specialty browser that handles their limited visibility needs or brail tool interface.
How can buying a specialty browser solve a problem of a blind person needing alt text for images?
You, as a developer, can determine when AI-generated text is good enough for your images—sometimes it is, and sometimes it isn't. A specialty browser cannot, and should not, be trusted to make that decision, so it will need hints from the developer. And, once the developer offers those hints, any mainstream browser, not just specialty products, can make use of them.
It sucks to be disabled and this is why it sucks. People shouldn't be wasting lifetimes of time to so that visually disabled people can be slightly more convenienced to browse the internet or play with an app. Especially with alt-text. Minimal effort is fine. Well structured HTML is all that should be needed.
> How can buying a specialty browser solve a problem of a blind person needing alt text for images?
If a picture is worth a thousand words you're never going to get the alt text right. There can always be complaints it's not good enough. Look at what happened to Dominoes. They made efforts but it wasn't good enough.
> It sucks to be disabled and this is why it sucks. People shouldn't be wasting lifetimes of time to so that visually disabled people can be slightly more convenienced to browse the internet or play with an app.
I think that a big part of why it sucks is that people feel comfortable expressing the idea that working to allow people of all abilities to enjoy the same conveniences is wasting time.
Domino's did not make an effort until they lost in court. They even admitted during the course of the case that the requested fixes would cost like $58,000 to make, far less than the lawyers cost in the case and appeals.
You are arguing they should have been forced to pay 58k for unnecessary site improvements when each place has a phone line that can be called. They did have alt text but it was deemed not good enough. What real value did disabled customers miss out on?
> They did have alt text but it was deemed not good enough.
Did they? Because the suit alleges that they did not have alt text.
> each place has a phone line that can be called.
Ok but what if the person has troubles talking or hearing or dialing the phone?
Accessibility doesn't even take that long. I updated a site I run to be compliant in less than a day. Corporations can afford to meet regulations.
Edit:
According to the lawsuit the phone number was not added too the website until after.
Also from the lawsuit
> But there are substantial reasons to believe that the
phone number does not provide the same level of independence and convenience as does the website and the
mobile app. In particular, as the district court noted,
"callers may experience delays and be placed on hold." Pet. App. 24a. Ambient noise may distract from and interfere with the accurate taking of orders. See p. 8, supra. And giving a credit card number to a live human
being over the phone may create a greater risk to privacy than does submitting that information through a
secure website. See DCt. Dkt. No. 33 at 15.
> But there are substantial reasons to believe that the phone number does not provide the same level of independence and convenience as does the website and the mobile app. In particular, as the district court noted, "callers may experience delays and be placed on hold." Pet. App. 24a. Ambient noise may distract from and interfere with the accurate taking of orders. See p. 8, supra. And giving a credit card number to a live human being over the phone may create a greater risk to privacy than does submitting that information through a secure website. See DCt. Dkt. No. 33 at 15.
This is pure nonsense. So what if you may experience delays or be put on hold. Just because something exists doesn't mean you're obligated to provide it.
"credit card number to a live human being over the phone may create a greater risk to privacy" is absurd, it's the way people been taking credit cards from inception to very recently, either it's not good enough and should be banned all together or it's an acceptable means of charging a card. Plus there is protection from the CC company.
Text contrast multiplies with the monitor contrast, which then multiplies again with eyesight quality. The high contrast requirement is to make it readable for someone with poor eyesight on a low-quality monitor...
Which then makes it downright painful for someone with regular eyesight, who sets their monitor to high contrast to improve photo rendering. Grey-on-grey is the only website design that doesn't make me immediately back away.
As you are using a site that is almost black text against a tan/grey background? For most copy I agree with you. But requiring that level of high contrast for titles, informational text, text over images, or some measure of flair so your site stands out a little it's too much of a requirement.
I guess if you're growing for the sake of growth you would do exactly that: not stop until everybody is using your app, because # of users (or rather, delta-# of users) is the most important metric. I agree it's a terrible metric, but isn't it the only VC-money-fuelled metric that counts in many cases (at least nowadays?)
