A mobile app is not a website, and the standard people cite for it is still WCAG, applied through each platform's own accessibility APIs. Most of the thinking carries over: names, roles and states, focus order, contrast, text resizing. What differs is the machinery, the testing tools and the store review. This page is what to reuse from the website work and what has to be done again for the app.
What carries over unchanged
Every content decision: alt text on images, captions on video, contrast ratios, error messages in text, and not carrying meaning by colour alone. Also the discipline: fix the components rather than the screens, because a mobile design system multiplies exactly the way nine web templates carrying 126 issues do.
What is genuinely different
Names and roles are set through the platform's accessibility API rather than through HTML, focus order is managed by the platform's screen reader, and touch target sizes and gesture alternatives matter far more. Every gesture-only action needs a non-gesture equivalent, which is the criterion mobile apps fail most often.
How to test it
Turn on the platform screen reader and use the app one-handed without looking. Then set the system text size to its largest and see what truncates. Between them these two runs find most of what an audit would, and neither needs a tool.
Questions people ask about ada compliance for mobile apps
Does the ADA cover apps?
The Department of Justice's guidance addresses web content and mobile apps together for the entities it binds; the practical standard is the same.
Do app stores check accessibility?
Not meaningfully. Passing review says nothing about conformance.
Can one audit cover site and app?
It can be one engagement, but it is two pieces of work with different tooling; expect the app to be priced by screen rather than by page.