Improve accessibility in an AI mobile app: names, focus and adaptable text

A worked example: where the task becomes difficult

A fictional appointment app uses unlabeled icon buttons for reschedule and cancel. A screen reader announces only “button,” and larger text truncates the appointment time. Begin with the booking-detail journey, naming controls by purpose and checking the runtime’s actual accessibility props. Keep the destructive action distinguishable from the ordinary edit action without relying only on color.

Decisions to make before implementation

Separate visual text, accessible name, role, state and hint. Avoid labels that repeat irrelevant decoration or describe an icon rather than its action. Preserve focus after a modal closes and communicate errors near the affected field. Check dynamic updates and loading states without overwhelming announcements. Include reduced motion where animation affects comfort or comprehension.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Choose one important task and inspect its current accessible structure.
• Add purpose-based names and appropriate role and state information.
• Repair text scaling, focus return and error association.
• Test the journey using the target platform’s accessibility tools.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Improve the appointment-detail journey using this mobile runtime’s accessibility contract. Name icon actions by purpose, expose relevant states and preserve focus through confirmation. Support larger text and reduced motion where needed. Test with platform tools and report the actual coverage; do not claim complete accessibility certification from labels alone.

Failure modes that an attractive preview can hide

Automated inspection can find missing labels but miss confusing navigation or announcements. Avoid claiming conformance from a single scanner. An icon’s filename is not a useful accessible name. Native and web accessibility APIs differ, so apply the current runtime contract rather than copying arbitrary HTML attributes into native components.

Technical references: Expo: start developing

Acceptance checks and the evidence to retain

Keep the task-level findings, changed semantics, text/focus checks and platform evidence. Prioritize failures that prevent completing the journey.

Specific answers

Common questions