Decide what the business really needs
Imagine a fictional Budapest coworking space adding a tour enquiry to its app. Reception needs a name, a reply address and a preferred visit period. Company size and billing details can wait. The W3C forms tutorial favors collecting only what a task needs.
Ask reception to justify each proposed field with a concrete follow-up action. Making a phone number optional allows an email-only enquiry, but staff must then handle that response channel. Requiring an account may help returning members, yet it adds another task for first-time visitors. Decide these trade-offs before designing the form.
Make each field understandable during entry
W3C's labeling guidance connects each control with a description of its purpose. For this enquiry, use a visible label such as Email for our reply, and keep it visible after typing starts. Put the explanation of an optional telephone number beside that field, where a visitor needs it.
During review, type an address containing a plus sign and a phone number with an international prefix. Ask the developer to choose suitable input modes, then check that the necessary characters remain available. With the keyboard open, try reaching the final action without losing your place. Review actual entry, not only a screenshot.
Write the recovery conversation
W3C recommends clear feedback that explains how to correct errors. Write a missing-email message before implementation, then ask a colleague to act on it without coaching. Would they know which field to change and what the app expects? Check that correcting it leaves the preferred visit period intact.
Separate requesting a tour from receiving an appointment. In this example, reception still needs to agree a time, so the confirmation should describe an enquiry received, not a visit booked. Ask staff to approve that wording. Also agree what visitors should see when the app cannot confirm receipt, rather than improvising during launch.
Test the interaction with assistive technology
React Native provides accessibility labels and roles, with platform differences. Ask for a demonstration using VoiceOver on iOS and TalkBack on Android. Have the reviewer find the enquiry, enter details, repair a mistake and identify the result. Record where they need help instead of accepting a simple accessibility-enabled claim.
If a custom visit-period selector is proposed, compare it with a simpler control using the same task. The custom version may suit the brand but needs time for implementation and device testing. Agree who will maintain it. Involve people who regularly use the relevant assistive technology when planning the review.
Give the team a clear acceptance checklist
Use the following checks as a shared release conversation, and give each issue an owner. They are a practical starting point for this form, not a complete accessibility audit.
- Submit a realistic enquiry using larger text and the on-screen keyboard.
- Leave a required field empty, correct it and retain the other answers.
- Complete the same task with the screen readers on both supported platforms.
- Have reception confirm that the success message matches its actual next step.
- Repeat these checks when field requirements or form components change.