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 establish 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 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 | Follow 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 should remain visible in the current orientation; a layout on one screen does not establish that they will |
| 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 visible setting |
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.
These are accessibility expectations. They do not establish 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
With larger text and longer translated copy, a customer should 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. Reading order, back direction, numeric content, forms, tabs, modals, and mixed-direction text can differ by screen.
Animation and haptic feedback should not be the only signal of a state change. Reduced-motion and device haptic preferences can vary by platform; this guide does not promise that every current animation or vibration honors them.
Screen-reader boundaries
VoiceOver and TalkBack can expose different accessibility trees and navigation patterns. An accessible experience should provide:
- 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; and
- large-text reflow and touch-target reachability.
A label visible in one screen does not establish equivalent VoiceOver or TalkBack behavior on another platform.
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.
Before using a permission, Settings, media, location, link, call, or provider handoff, remember it can open a device or third-party flow. Do not open Settings or a provider simply to test a screen.
Troubleshooting safely
A control is missing or difficult to reach
Confirm the current 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 make sure 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 just to make the screen fit. When asking for help, describe the value-free state, device class, language class, and text-size class.
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.
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