Digital accessibility has become a steady source of lawsuits in the United States. Plaintiffs filed 5,114 ADA digital accessibility lawsuits in 2025, covering websites, mobile apps and video, according to UsableNet's year-end report, and 1,427 of those cases targeted companies that had been sued before. Apps sit inside that picture, and California adds pressure of its own.

For a startup, accessibility costs less before launch than after it. When a founder briefs a mobile app development company in San Francisco, accessibility belongs in the acceptance criteria for every screen, next to performance and security.

Why California Raises the Stakes

In 2019, the federal appeals court for the Ninth Circuit, which covers California, ruled in Robles v. Domino's Pizza that the ADA applied to Domino's website and app, because both connected customers to its restaurants. The Supreme Court declined to hear Domino's appeal later that year.

State law raises the cost of a violation. California's Unruh Civil Rights Act treats an ADA violation as a violation of state law and allows statutory damages of at least $4,000 per violation. Quick fixes don't stop the filings either. UsableNet's report notes that accessibility widgets did not slow litigation in 2025.

Build for Screen Readers From the First Screen

Blind and low-vision users move through an app with VoiceOver on iPhone and TalkBack on Android. Both read out what is on the screen, so every button, icon and image needs a clear label. An icon button without one is read as "button," and the user has to guess what it does. Hide purely decorative images from the screen reader, so users don't hear "image" again and again.

Set a logical reading order, group related items, and make custom controls report their role and state, such as "switch, on." Then run the core flows with the screen reader turned on: sign-up, search, checkout and account settings. A mobile app development company San Francisco founders hire should run these checks on real devices before each release and share the results.

Support Larger Text and Strong Contrast

Many users raise the text size on their phone. Apple's Dynamic Type and Android's font scaling only help when layouts grow with the text, so avoid fixed heights and test the top text sizes on a small phone. Text inside images, such as banners, needs a text alternative too.

Contrast matters just as much. The Web Content Accessibility Guidelines, the standard most settlements refer to, call for a ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. Never use color alone to carry meaning. An error shown only as a red border needs a text message as well.

Make touch targets large enough to hit. Apple recommends at least 44 by 44 points, and Google's Material Design recommends 48 by 48 density-independent pixels.

Cover Motion, Media and Time Limits

Animations can cause discomfort for some users, so respect the system's Reduce Motion setting and offer a calmer version of any large transition. Keep gestures simple, and offer a button for any action that needs a swipe or a long press, since some users can't perform complex gestures. Add captions to video, and audio descriptions where the picture carries information. Give users enough time on forms and checkouts, and warn them before a session times out.

Show What You Support in the App Store

Apple now asks developers to declare their accessibility support through Accessibility Nutrition Labels. They cover nine features: VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color Alone, Sufficient Contrast, Reduced Motion, Captions and Audio Descriptions. The labels appear on the app's product page on devices running iOS 26 or later.

Apple has made the labels voluntary to start and says developers will have to provide accessibility details for new apps and updates over time. Fill them in accurately. A label that promises VoiceOver support invites users who will notice right away if the app falls short.

Make It Part of Every Release

Use the free tools that come with each platform: the Accessibility Inspector in Xcode and the Accessibility Scanner app on Android. Automated checks catch missing labels and low contrast. Manual testing with VoiceOver and TalkBack catches the rest, and sessions with users who rely on assistive technology catch what testers miss. Fix accessibility bugs in the sprint they are found, with the same priority as a crash.

At AppVerticals, for example, a screen reader pass sits in the test plan for every release, next to device and performance testing. Whoever builds your app, ask to see that pass in writing.

Publish an accessibility statement in the app and on the website, with a way for users to report problems. A clear route for feedback helps you fix issues early and shows users that the team takes them seriously.