Language, device, and accessibility considerations
Customer App can vary with the device, language availability, screen size, and the current customer experience. A control or message shown on one device may not appear in the same way on another.
This guide does not certify accessibility compliance, equivalent iOS and Android behavior, dark-mode support, global right-to-left layout, permission parity, or a specific screen-reader result. Use the current visible experience and an approved device-specific verification when the exact behavior matters.
iOS and Android can present different paths
| Area | What can differ | Safe interpretation |
|---|---|---|
| Navigation and Back | Visible back controls, gestures, and Android system Back can follow different platform rules | Verify one transition at a time; do not assume the same control or result exists on both platforms |
| Orientation and safe area | Supported orientation, status/navigation areas, cutouts, and bottom insets depend on the distributed app and device | Important content and actions must remain visible in the tested orientation; source layout alone is not proof |
| Keyboard and forms | Keyboard size, resize behavior, Next/Done actions, focus movement, and field visibility vary | Keep the focused field and its error/action reachable; do not submit solely to dismiss the keyboard |
| Permissions and Settings | The operating system owns permission status, prompts, blocked state, and Settings | An in-app control does not prove that a prompt appeared or that permission changed |
| Media and external intents | Photo libraries, maps, calls, links, provider screens, and other apps are platform-owned handoffs | A handoff does not prove that the external action completed or that Customer App state changed |
| Theme and presentation | Packaged presentation, remote experience, font rendering, contrast, and device settings can alter appearance | Do not infer dark-mode or contrast support from one screenshot or source value |
Language and screen differences
Use the language and display choices that Customer App currently makes available. Longer text, screen size, and device settings can affect how a screen is presented.
- A translated label can be longer or use a different reading direction.
- A language listed by the app does not prove that every screen is translated or that the entire interface mirrors for right-to-left reading.
- Large text can reflow, wrap, truncate, or move an action below the initial viewport.
- Icons, color, position, or placeholder text must not be the only way to identify a control or state.
If text is missing, untranslated, clipped, or out of order, keep the current task unchanged and use another clearly labeled in-app path when one is available. Do not change a live project or private configuration to force a language.
What an accessible screen should communicate
A usable Customer App state should make the following information available without relying on appearance alone:
- the screen heading and current section;
- the name and role of each actionable control;
- selected, checked, expanded, disabled, required, invalid, loading, and busy states when they apply;
- the relationship between a field and its help or error message;
- the current focus when a modal, sheet, alert, or new screen opens;
- a safe close or return action; and
- important loading, error, success, and unavailable status changes.
This is the required verification posture. It is not a claim that every current screen already exposes these semantics.
Focus, modals, and status messages
When a modal, sheet, or alert opens, assistive focus should move into it, background content should not remain actionable, and focus should return to the trigger after close. Android system Back and an in-app close control should not produce two transitions.
Loading indicators, form errors, toasts, connection state, and completion messages should be announced at the appropriate time without repeatedly stealing focus. A disappearing toast or a color change alone is not reliable recovery guidance.
Large text, reading direction, and motion
Verify representative screens with larger text and longer translated copy. The customer must still be able to read the purpose, reach the primary action, review errors, and scroll without overlapping fixed controls.
Right-to-left metadata or a mirrored icon on one screen does not prove global right-to-left support. Verify reading order, back direction, numeric content, forms, tabs, modals, and mixed-direction text separately before documenting an RTL experience.
Animation and haptic feedback should not be the only signal of a state change. Reduced-motion and device haptic preferences require platform-specific review; this guide does not promise that every current animation or vibration honors them.
Screen-reader verification
VoiceOver and TalkBack can expose different accessibility trees and navigation patterns. An approved check should use synthetic, non-sensitive content and verify:
- heading and focus order;
- control names, roles, values, and states;
- field/error relationships and keyboard navigation;
- modal isolation, close, Back, and focus restoration;
- loading/error/status announcements;
- large-text reflow and touch-target reachability; and
- zero permission, Settings, provider, media, location, message, order, payment, account, or other real effect.
A source label or automated selector is useful evidence, but it does not replace an iOS VoiceOver and Android TalkBack review of the current build.
Permissions and device controls
Some customer features can depend on device-level choices. Customer App does not guarantee a permission prompt, a particular accessibility behavior, or the same result on every platform. This guide does not ask you to change device permissions or settings.
Review permission, Settings, media, location, link, call, and provider handoffs before the action. Use a synthetic denied/unavailable state for documentation; do not open Settings or a provider to manufacture evidence.
Troubleshooting safely
A control is missing or difficult to reach
Confirm the intended screen, account/business/order prerequisites, language, text size, orientation, keyboard, and current modal. Use another clearly labeled in-app path if available. Do not assume another platform has the same layout.
The keyboard covers a field or action
Scroll without submitting, then verify that focus, the field label, its error, and the next supported action remain reachable. Do not treat keyboard dismissal as form completion.
Back or close returns somewhere unexpected
Stop before repeating the action. Record the screen class and platform with private identifiers removed. Android system Back, a modal close, and visible navigation can have different owners.
A screen reader does not announce a change
Keep the underlying action unchanged. Look for a visible status or safe return path; do not repeat a payment, order, message, account, or provider action to force an announcement.
Large text or translation hides meaning
Do not reduce text size as proof that the screen is accessible. Record the value-free state, device class, language class, and text-size class for the accessibility owner.
A permission or external handoff stops the flow
Treat permission status and external completion separately from Customer App. Return to the app and verify its final visible state without assuming the handoff succeeded.
When to recertify
Repeat representative iOS and Android review after changes to shared controls, navigation or Back handling, safe-area or keyboard behavior, modals/toasts, translations or RTL handling, font scale/layout, motion/haptics, permissions, media/external intents, native/provider integration, or App/shared-components/ API authority pins.
Related references: Location permission and unavailable-location states · Account settings · Privacy consent choices · Customer App experience variants · Startup, connection, and update states · Native integration boundaries