Start from the action, not the template
A form builder often marks fields required because the template shipped that way. That is a weak reason to demand information from a customer. First write the action the form promises: perhaps a reply to a product question, a callback request or a service quotation. For each field, ask whether staff can complete that action without it. W3C's forms tutorial advises collecting only information required for the transaction or process. If an email reply is the service, an email address and a question may be necessary; a telephone number, job title and company size might be optional or unnecessary. If the requested action is a callback, the telephone may become necessary, but the interface should say why.
Make a field decision table with four columns: field, purpose, required status and reason. Include the person who owns the decision, because a request from sales or support may reflect a preference rather than a requirement for the customer's chosen action. Separate operational need from future marketing convenience. If a field is only useful for triage, consider whether staff can ask a follow-up after the initial contact instead of blocking submission. Revisit the table when the form gains a new purpose. A form that serves several actions may need a first-step choice so a callback request and a general question do not inherit the same mandatory fields.
Give every control a persistent label
W3C's labeling guidance covers text inputs, checkboxes, radio buttons and drop-downs. In common HTML forms, a visible label associated with its control through matching for and id values makes the relationship available to assistive technology and increases the clickable area. Use a label that states what the customer is entering, such as 'Email for our reply', rather than a vague word like 'Contact'. A placeholder can show an example, but it should not be the only label because the example may disappear as the customer types. Check the final rendered page, not only a design mockup or a component name in the codebase.
For a group of choices, label both the overall question and each option. 'Preferred reply method' as a group heading is not enough if the individual radio choices are unlabeled; conversely, isolated 'Email' and 'Phone' options are unclear without the question. W3C describes fieldset and legend as a way to associate a group description with related controls. Write the options so their consequences are clear: 'Reply by email' and 'Call me' are more useful than bare channel names. If choosing Call me reveals a telephone field, update its required state and explanation at the same time. The label and the rule must change together, including for keyboard and screen-reader users.
Show required status before submission
The HTML required attribute tells the browser that a supported control must have a value before submission. MDN also says to provide a visible indication near the control; a red border alone is not enough for everyone. Use words such as 'Required' or '必填' in the label or adjacent instruction, or explain a consistently used symbol at the start of the form. Do not rely solely on a legend at the top if customers can arrive midway through a long form on mobile. If most fields are required, it can be clearer to label the few optional ones explicitly and state the general rule, but inspect whether every customer can infer each field's status at its location.
Keep three layers in agreement: the visible statement, the control's programmatic state, and the server's acceptance rule. A label saying Optional beside an HTML required input contradicts itself. An aria-required flag can communicate a state to assistive technology but, as MDN explains, it does not make the browser enforce entry. Conversely, a server that rejects an apparently optional telephone number creates a surprise after submission. Define the rule once in product requirements, then verify each layer. When a conditional field becomes required, apply the change while it is relevant and let the customer know before they attempt to submit. Do not mark a hidden field required when the chosen path cannot reach it.
Explain constraints where they matter
A required marker says that a value is needed; it does not tell the customer what counts as acceptable. W3C's Labels or Instructions criterion covers labels or instructions whenever content accepts user input, including optional fields. Add concise help next to fields with unusual formats, length limits or evidence requirements. For example, a quotation request might need a project location to determine service coverage, but 'Location' alone does not tell the customer whether to enter a district, full address or site name. If a full address is not needed until later, ask for the district now and say so. Avoid inventing an arbitrary format rule for a field that can accept ordinary text.
An example should illustrate the accepted answer rather than become a hidden rule. If the form says 'Phone number, for example 9123 4567', it should not reject every valid number written with a different spacing pattern unless there is a documented business need. If an attachment is required for a particular request, say what document is needed, which file types and size limits apply, and what alternative the customer has if they cannot provide it yet. Keep instructions beside the action they govern so a person using magnification or a small screen need not remember a distant paragraph. Test the wording in both languages with the same acceptance cases.
Work through a conditional enquiry
Imagine a small retailer with a form that handles general product questions and callback requests. The first control asks the customer to choose one path. A product question needs a message and a reply email. A callback request needs a question or topic and a telephone number; email may remain optional if staff can complete the call without it. The exact choices are a shop policy illustration, not a legal rule. If the customer switches from callback to email, the telephone should cease to be required, while previously typed text should be handled predictably. A confirmation should reflect the channel chosen, so the customer knows what happens next.
Write a compact test table before implementation: empty submission on each path, one missing required value, an optional value omitted, a path switch after partial entry, and a correctly completed request. For each case note the expected visible labels, browser state and server response. The form should never imply that an optional field is mandatory just because a staff workflow prefers it. If the business cannot process a request without extra information, either make the requirement explicit before submission or offer a narrower action the customer can complete now. This avoids a form that is technically valid yet operationally unusable.
Review the rendered form and its outcomes
Review the live rendered form with keyboard, touch and a screen reader. Move through every control and listen for its label, group question, required state and nearby instruction. Then try submitting an empty form and observe whether the browser's validation points to the correct visible field. MDN notes that required works on supported inputs, select and textarea, but not every input type; a custom control may need its own implementation and tests. A native required attribute is useful, yet server validation remains necessary because a request may bypass the browser. Verify that both layers agree on the same conditions rather than just checking that each shows an error somewhere.
Finally ask someone outside the form project to complete one realistic enquiry in English and another in Traditional Chinese. Give them the task but do not explain which fields to fill. Watch where they hesitate: an unexplained asterisk, an ambiguous company field, or a phone number that becomes mandatory unexpectedly all reveal a decision problem. Record the observation as a usability check, not as a claim about conversion or legal compliance. Fix the labels, instructions or rule where the hesitation points, and repeat that path. The release criterion is simple: the customer can tell what is necessary before submitting, and a valid request reaches staff with enough information to perform the promised action.
Before you proceed
- Can the business explain why every required field is necessary for the chosen action?
- Do visible labels, HTML states and server rules agree in both languages?
- Can a customer identify the expected answer before submitting?
