Mobile App Development: How to Judge Accessibility Requirements
Accessibility requirements in the EU and North America turn on evidence, not assurances. Apply three criteria: a conformance target named in the contract, a platform choice justified by your field conditions, and a maintenance budget tied to OS update cycles.
Mobile app development for European and North American markets now carries accessibility obligations that a buyer must test before signing. Ask for three things: a named conformance standard with a test method, a written reason for native versus cross-platform, and a maintenance plan priced against annual OS releases. If a vendor cannot name the standard and the test, the accessibility claim is marketing, not engineering.
What accessibility standard should a mobile app meet in the EU and North America?
The applicable standard depends on who your users are and where you sell, but WCAG 2.2 Level AA is the common reference point that both EU and North American buyers accept in a contract. In the EU, the European Accessibility Act applies to many consumer-facing services from June 2025 and points to EN 301 549, which incorporates WCAG. In the US, the ADA has been applied to mobile apps through case law and the Department of Justice has repeatedly referenced WCAG 2.1 AA as the technical benchmark.
A serious proposal will name the standard, the conformance level, and the assistive technologies tested, such as VoiceOver on iOS and TalkBack on Android. It will also state who runs the audit and what happens to defects found after launch. If the acceptance criteria do not include a screen-reader pass on a real device, the app is not being tested for accessibility.
For a New York reader, the practical trigger is often a customer or a public-sector contract: a transit agency, a hospital network, or a retailer with a Manhattan storefront will ask for a VPAT or an accessibility conformance report before they let staff or customers use the app. Preparing that document after launch is more expensive than designing the labels and focus order at the start.
Should I build a native app or a cross-platform app for field staff?
Choose native when the app depends on device hardware or background behavior that a cross-platform layer abstracts poorly, and choose cross-platform when the screens are forms, lists and sync. Native versus cross-platform is a decision about which platform APIs you need, not about fashion. A driver app that scans barcodes, captures signatures, and must keep working in a basement or a tunnel is a hardware-and-offline problem first.
Cross-platform app development with Flutter or React Native can cover most business workflows, and it reduces the cost of maintaining two codebases. The trade-off appears when a plugin lags a new OS release or when a camera or Bluetooth stack needs a native module anyway. If more than one core feature needs a platform-specific module, the cross-platform saving shrinks and the native case gets stronger.
| Criterion | Strong answer | Weak answer |
|---|---|---|
| Accessibility standard | Names WCAG 2.2 AA and EN 301 549, with device test plan | Says the app will be accessible without naming a standard |
| Platform choice | Explains which device APIs drive the decision | Recommends one framework for every project |
| Offline behavior | Describes the local queue and conflict rule for edits | Says the app will sync when the connection returns |
| App store review | Lists the review risks and who fixes a rejection | Assumes approval is automatic |
| Maintenance cost | Prices annual OS updates and store compliance separately | Quotes a single support percentage with no scope |
The table is a scoring sheet, not a script. Score each row out of three and require a written answer for any row that scores one. A vendor who scores well on platform choice but cannot describe the offline conflict rule will fail in a warehouse or a delivery route.
Why do apps get rejected from the App Store, and how do we prevent it?
Most app store review rejection comes from metadata and policy gaps rather than from broken code: missing privacy disclosures, account deletion not available in-app, or a login wall that hides the product from the reviewer. Apple's App Store Review Guidelines and Google Play policies both require a privacy policy, accurate data-collection declarations, and a way to delete an account if the app creates one. A rejection costs days, not hours, because the review queue restarts.
Prevention is a checklist run before submission, not after. The delivery team controls the build and the declarations; the client controls the privacy policy text, the legal entity details, and the demo account credentials. If the client cannot supply a working demo login and a published privacy policy, the submission is not ready.
- Account deletion path visible inside the app, not only on a website.
- Privacy nutrition labels and data-safety form completed to match actual SDK behavior.
- Demo credentials and reviewer notes supplied for any login-gated feature.
- Screenshots and description that match the build, with no placeholder content.
- Age rating and content declarations completed for the target storefront.
Offline-first app design adds a review dimension: if the reviewer tests on a poor connection and sees an empty screen, the app may be judged incomplete. State in the reviewer notes that the app is designed for intermittent connectivity and describe how to reach a populated state. For a New York field team, the same design matters in the subway and in older buildings where signal drops between floors.
What does app maintenance cost after launch, and what drives it?
App maintenance cost after launch is driven by OS release cadence, store policy changes, and the number of third-party SDKs in the build, not by a fixed percentage of the original price. Apple and Google ship major OS versions annually and change review rules through the year, so every app needs a budget line for compatibility work. A simple forms-and-sync app with two SDKs needs less than a camera-heavy app with maps, payments, and push notifications.
Ask for the maintenance plan in three parts: OS and store compliance, defect fixes, and small enhancements. If the maintenance quote does not separate compliance work from feature requests, you cannot compare it with another vendor's quote. The client controls the enhancement list and the priority; the delivery team controls the compatibility testing and the release process.
A progressive web app versus native app decision changes the maintenance profile. A PWA avoids store review and updates instantly, but it has limited access to background location, Bluetooth, and some camera features, and its offline storage can be cleared by the browser. If the workflow depends on background location or hardware access, a PWA will not replace a native or cross-platform build.
We deliver custom mobile app development from Chengdu for clients in Europe and North America, and we scope maintenance as a separate annual line with named compatibility work. The same applies to the wider mobile app development practice: the plan is written before the build starts, not negotiated after the first OS update.
How much does it cost to develop a mobile app, and what should the quote show?
The cost of custom mobile app development depends on the number of distinct workflows, the number of device integrations, the offline rules, and the accessibility scope, so a single figure without those inputs is a guess. A quote should show the screens or user stories, the integrations, the test devices, and the accessibility audit as separate lines. If the quote has one total and no line items for integrations and testing, you cannot tell what you are buying.
For a restaurant group, the same logic applies to a floor app for order taking and table turns; the scope is the workflow, not the platform. The restaurant industry page shows how those workflows are usually split. For a European roll-out, the app development service in Europe describes the localisation and accessibility inputs that change the estimate.
A New York buyer should also ask about device fleet and carrier conditions: older handsets, shared devices, and building interiors change the test plan and therefore the cost. The New York regional page covers the operating context we plan for. If the quote does not state which devices will be tested, the acceptance test is undefined.
Frequently asked questions
How much does it cost to develop a mobile app?
The cost of mobile app development depends on the number of workflows, device integrations, offline rules, and accessibility scope, so no single figure applies to every project. A useful quote breaks out screens or user stories, integrations, test devices, and the accessibility audit as separate lines. Without those inputs, any total is an estimate rather than a price.
Should I build a native app or a cross-platform app?
Choose native when core features depend on device hardware or background behavior that a cross-platform layer handles poorly. Choose cross-platform when the app is mainly forms, lists, and sync, because it reduces the cost of maintaining two codebases. If more than one core feature needs a platform-specific module, the cross-platform saving shrinks.
Why do apps get rejected from the App Store?
Most rejections come from metadata and policy gaps such as missing privacy disclosures, no in-app account deletion, or a login wall that hides the product from the reviewer. Both Apple and Google require a privacy policy and accurate data-collection declarations. A pre-submission checklist covering demo credentials and deletion paths prevents most of these.
How much does it cost to maintain an app after launch?
Maintenance cost after launch is driven by annual OS releases, store policy changes, and the number of third-party SDKs, not by a fixed percentage of the build price. Ask for a plan that separates compliance work from defect fixes and enhancements. That separation is what makes two maintenance quotes comparable.
What accessibility standard should a mobile app meet in the EU and North America?
WCAG 2.2 Level AA is the common contract reference, and in the EU it sits inside EN 301 549 under the European Accessibility Act. In the US, the ADA has been applied to mobile apps with WCAG 2.1 AA as the technical benchmark. A proposal should name the standard, the level, and the assistive technologies tested on real devices.
Questions we are asked
How much does it cost to develop a mobile app?
The cost of mobile app development depends on the number of workflows, device integrations, offline rules, and accessibility scope, so no single figure applies to every project. A useful quote breaks out screens or user stories, integrations, test devices, and the accessibility audit as separate lines. Without those inputs, any total is an estimate rather than a price.
Should I build a native app or a cross-platform app?
Choose native when core features depend on device hardware or background behavior that a cross-platform layer handles poorly. Choose cross-platform when the app is mainly forms, lists, and sync, because it reduces the cost of maintaining two codebases. If more than one core feature needs a platform-specific module, the cross-platform saving shrinks.
Why do apps get rejected from the App Store?
Most rejections come from metadata and policy gaps such as missing privacy disclosures, no in-app account deletion, or a login wall that hides the product from the reviewer. Both Apple and Google require a privacy policy and accurate data-collection declarations. A pre-submission checklist covering demo credentials and deletion paths prevents most of these.
How much does it cost to maintain an app after launch?
Maintenance cost after launch is driven by annual OS releases, store policy changes, and the number of third-party SDKs, not by a fixed percentage of the build price. Ask for a plan that separates compliance work from defect fixes and enhancements. That separation is what makes two maintenance quotes comparable.
What accessibility standard should a mobile app meet in the EU and North America?
WCAG 2.2 Level AA is the common contract reference, and in the EU it sits inside EN 301 549 under the European Accessibility Act. In the US, the ADA has been applied to mobile apps with WCAG 2.1 AA as the technical benchmark. A proposal should name the standard, the level, and the assistive technologies tested on real devices.
