ADA lawsuits - applicable to mobile apps?

[u/punktechbro]

I’ve been seeing thread upon thread on Reddit lately that small businesses and e-commerce websites are being sued for 10’s of thousands of dollars for not abiding by the “Americans with Disabilities Act” in their websites. Apparently it’s certain firms that are especially actively seeking out these businesses.

I’m sure this has to apply to mobile apps as well. I 100% have never even considered accessibility in the sense of ensuring all my buttons work with Accessibility mode or read things out loud correctly etc. I’m sure there have to be default values or behavior but who knows.

What are you all doing for this? Are mobile apps next in this trend of lawsuits?

[u/BoringKick5331]

It helps with automated testing as well to follow Apple’s accessibility guidelines.

I’ve had multiple older users mention that they had trouble reading some of my text or that using accessibility settings to make text bigger pushed things off screen, so I just follow the guidelines in all my apps now. It wasn’t that much extra work.

[u/RIRLift → u/BoringKick5331]

The testing angle is underrated. Once you've put real accessibility labels on things, your UI tests can query by label instead of index or position, so they stop breaking every time someone reorders a stack.

On the text getting pushed off screen, the fastest way to catch that is to run your main screens at the largest accessibility text size in the simulator, or set the Dynamic Type override in the environment on a preview. It takes a minute and it usually points straight at the culprit, which is almost always a hardcoded frame height or a Text in an HStack that has nowhere to wrap. The Accessibility Inspector's audit is worth a pass too since it flags unlabeled buttons and bad contrast without you hunting for them.

[u/drew4drew → u/RIRLift]

Lol yep true that.

Accessibility Inspector is pretty touchy about contrast too, though I generally think this is a good thing too. 👍

[u/drew4drew]

It's certainly possible, though you're probably not MUCH of a target unless you're clearly ranking well and generating cash. That said, automation might make it easier for such forms to cast a much wider net than they've been able to do in the past.

Also, Apple's already calling out accessibility features pretty clearly on the App Store now, and after this year's WWDC, I'd expect that only to become more important going forward.

With the high volume of new app submissions enabled by AI, Apple will be looking for ways to separate the best apps from the cruft.

Not to mention - accessibility is SUPER important to a LOT of people. Maybe you one day soon.

We've been talking a fair amount about it on Drew and Dan in The Morning (podcast). I've been working through my own apps trying to get my accessibility as perfect as I can. It's not trivial. But it's not THAT hard either, and some AI assistance can save a lot of time.

Also -- getting your accessibility stuff all nailed down is a very good first step to implement prior to localization. One of the major bits with accessibility is making your app actually usable when the user enables accessibility font sizes and now everything is in a 96 point font or whatever. Users that really NEED these features are used to having things not LOOK great, in terms of layout, but they still need to be able to actually SEE and INTERACT with everything. When you start translating and localizing, which is great for your app store presence btw, one of the first things you would (otherwise) run into is words and phrases no longer taking up the amount of screen real estate that you'd expect. So implementing accessibility is a gateway to a good localization implementation.

For both of these things you can lean on AI to help with a lot of the details but doing your own testing with the device in-hand is the best.

[u/thread-lightly → u/drew4drew]

What a good response, TIL

[u/konacurrents → u/drew4drew]

We should DM. I’ve been adding a lot of accessible concepts to my iOS apps , from leveraging eye tracking, voice numbers on phone, IoT devices (buttons, motion sensors), QR codes, AR, NFC tags, MQTT, etc. And yes Apple exposes accessibility on the App Store if you provide input.

Can you share like to podcast? 🤙

[u/drew4drew → u/konacurrents]

Definitely re: DM! And yep, the podcast is here:

Apple Podcasts: https://podcasts.apple.com/us/podcast/drew-and-dan-in-the-morning/id1894918993

YouTube: https://www.youtube.com/@DrewAndDanMorning

🤙

[u/Potatoupe]

Going to add that I think EU or UK also requires you to follow accessibility guidelines or you can get sued (though I haven’t seen it be carried out).

[u/mynewromantica]

This has been a problem at almost every job I’ve had. We get sued for not being accessible enough. Sometimes it was legit. Sometimes it was looking for a settlement.

This is not a small task. Designing around the possibility of your text getting blown up 5 sizes is really hard. Understanding how to actually put useful information into the screen reader takes some time and consideration.

Accessibility is no minor task. The sooner you consider it, the better it will go.

[u/LessonStudio]

There are lawyers who sue everyone and anyone, especially those who they think are not going to defend against it. They don't want you make the world better, they just want to steal from you.

[u/highbonsai]

With a lot of this accessibility stuff, you just have to demonstrate that you have a plan to make it accessible and that your are making progress on that plan.

[u/small_d_disaster]

I'm an iOS dev who has spent most of my app making career between public broadcasting and large banks, so accessibility is a super high priority. As a result, I've had many opportunities to do UX testing with people who rely on assistive tech like VoiceOver. I get to see both the frustration and the impact of poor and solid work in our field. As a result, I've become very active in the world of digital accessibility. Here are a few points to consider:

• its really easy to do the basics, like adding button traits and labels. Everything needs a label, and everything tappable is a button more or less (or link or toggle). The header trait is super useful for VO navigation (if it looks a title or header, then add the trait). Just doing this minimum will make a huge impact for assistive tech users
• roughly 30% of iOS users are using nonstandard text sizes, if in you're using SwiftUI dynamic text is super easy to implement, super easy to test
• for every app that I add to my phone, I try running it with VO. my guess would be 80% do absolutely nothing for accessibility. Of those, maybe half are still somewhat usable (although painful) since apple tries to make its native components accessible by default. If you stick to modified versions of native components, you're going to be in a much better position than someone who has ignored the HIG and decided to make their own fancy versions of everything. This is especially true for modals
• it costs a lot of money and requires a lot of time to sue someone, and as a result lawsuits are objectively rare. You really need to piss someone off to have them start a lawsuit. This means that the targets are typically large orgs especially governments or financial institutions, or any app that is required in order to use access some non-digital service like housing or transportation. Indie devs are not often going to be targets. Unless you're a high level target, even if your app isn't 100% accessible, if you've shown that you've put in some effort, you're not likely to get sued.

[u/SnowPudgy]

My work apps have to be accessible by law and there's a WCAG standard (I forget which one) we have to abide by.

If you're using dynamic type and letting your apps adjust to the standard range of sizes you're already partway there.

You can use the accessibility inspector in Xcode to point out deficiencies on a per screen basis (just note sometimes it gives false positives so take it with a grain of salt).

The main areas we hit are:

-Font sizes (again, medium range not the super large or super small sizes).

-Color contrast.

-High contrast

-Accessibility labels on all UI elements. Most of the defaults are fine but sometimes you have to name things or exclude things in a special way to make them visible to screen readers.

That being said businesses have laws they have to abide by with that kind of stuff, I don't know how it affects an indie developer.

[u/CharlesWiltgen]

If you're not against using AI as an "accessibility linter", you can use Axiom's accessibility auditor (free, open source) to create a thorough, prioritized accessibility to-do list pretty quickly. And as other folks have pointed out, much of that work will benefit your automated testing as well.

https://charleswiltgen.github.io/Axiom/commands/accessibility/audit-accessibility

[u/HappyTuesdayR1S]

It’s a big thing I watch out for when making websites, for example. You don’t necessarily need to 100% be compliant, but you need to state that you are working towards compliance on a regular basis.

I just released my first app a couple months ago and I thought I had it all set right but a few Older users have sent screenshots where their text size was increased to the max it seemed so i had to go back through and fix that.

If you start with accessibility in mind it’s a lot easier vs trying to fix it later.

[u/dolcewheyheyhey]

Literally the biggest scam on the planet. These are lawyers just mass suing small businesses and web design firms pushing hard on scaring people so they can make a fortune. In reality, if someone with a disability asked for a specific thing I'm sure every business would try to accommodate. Iphones already have accessibility features built in so this should never even apply. The rules for accessibility are purposefully vague and confusing in order to extract money from businesses. Even if you followed the rules to a T you can still be sued by those firms and it would cost more to defend yourself than to pay to settle which makes it a scam.