Compare the displayed value with the field’s native eligibility, the prepared request and the accepted record; choose a locked state that matches the intended behavior.
A field can display the correct value while contributing nothing to a form’s native submission. Diagnose the difference between the screen, the data prepared for the request and the record the service accepts. Replacing one attribute at random may hide the first symptom while creating a different usability or data problem.
Consider a fictional equipment reservation form. The visitor selects a room, and a later step displays that room in a locked-looking field. The final request arrives without the room selection. The maintainer needs to learn whether the displayed control was excluded, whether another value was sent, or whether the server discarded an otherwise correct request.
Give every displayed value an explicit role
Classify the room information before editing its markup. Is it an answer the visitor must supply, a choice already recorded elsewhere, a calculated summary, or a fact the server should determine independently? The right representation depends on that role. A summary need not masquerade as an editable question, and a trusted system decision should not depend solely on a browser-supplied field.
The multi-step form guide covers progress and persistence. Here, concentrate on one value at the handoff between display and submission. Record the intended source of truth and the final record it should influence. This makes it possible to judge a fix by the reservation outcome rather than by its appearance.
Separate a locked appearance from native eligibility
| Displayed control | Native question to inspect | A useful acceptance condition |
|---|---|---|
| A disabled room field | Is its exclusion intentional? | The authoritative room value still reaches the intended processing path |
| A readonly text field | Is this supported and otherwise eligible? | The visitor can inspect it and the expected named value is prepared |
| A field without a name | Which key is supposed to represent it? | The intended request key and value are identifiable |
| A custom summary component | What constructs the real request? | The displayed summary agrees with the submitted and accepted values |
MDN’s disabled reference explains that disabled controls are excluded from native submission and constraint validation and cannot receive focus. A disabled fieldset can affect its descendants. Do not infer the state from a grey background: inspect the actual control and its context.
For the reservation form, first capture the room shown just before the final action. Then identify the element associated with that display. A template might contain a visible summary plus a separate value used by the application. Changing the summary would not necessarily change what the final request contains.
Use readonly only where its meaning fits
MDN documents readonly for supported controls: they remain focusable and can participate in submission, but are outside constraint validation. It does not apply to select, checkbox or radio controls, and required should not accompany it. Submission still depends on eligibility such as a name and the absence of disabling.
Readonly can suit a text value that visitors need to inspect or copy without editing in that location. It is not a universal replacement for disabled. If the room picker is a select menu, adding an irrelevant attribute does not define a dependable locked-picker design. Ask what interaction visitors need and implement that deliberately using the platform or form library’s supported pattern.
Explain why the value is fixed and where to change it if a change is allowed. In the fictional reservation, a Change room link could return to the appropriate step while preserving other answers. A locked field with no explanation leaves the visitor to guess whether the selection is final, loading or broken.
Trace prepared data separately from the sent request
The FormData constructor reference describes collecting named eligible controls and excluding disabled ones. Scripts, including a formdata handler, can modify that collection. Creating a FormData object does not itself send a request. An application may also construct a separate payload instead of using native form data.
Ask the authorized developer to compare three observations in a controlled environment: the prepared room key and value, the actual outbound request, and the service’s accepted record. Keep these distinct in the issue report. A value present in a local collection might later be replaced, omitted during conversion or rejected by the endpoint. A correct request might still produce the wrong stored association.
If the value changes before this stage, the autofill purpose and grouping guide may help. Do not attribute every missing value to autofill or to disabled controls merely because those mechanisms exist. Follow the first point where the observed value differs from the intended one.
Keep browser locks separate from authority
A noneditable interface is a usability choice, not proof that a request is trustworthy. The receiving service should establish which room the visitor may reserve and which contextual facts it accepts. Do not make a hidden copy of every locked field and assume that duplication solves authorization or consistency.
For the imaginary reservation, agree whether the server derives the room from a saved reservation reference or checks a submitted room identifier against permitted choices. The article does not prescribe a particular backend. The practical requirement is that an altered or stale browser value cannot silently become an unauthorized booking.
Treat loading and unavailable states carefully as well. If a field is temporarily disabled while choices load, decide whether the form may be completed during that interval. The same visible styling should not ambiguously mean loading, fixed by policy and failed to load. Give the visitor a clear next action for each state.
Propose a focused end-to-end value check
- Use harmless sample reservations in an authorized test environment and record the expected room identifier.
- Compare the display with the actual control state, name and association to the form at the moment of submission.
- Check the prepared data, outbound request and accepted record without exposing real visitor details in screenshots or tickets.
- Repeat after returning to an earlier step and choosing another room; the final summary must agree with the accepted choice.
- Review the loading and failure paths so a temporary disabled state cannot produce an unexplained incomplete request.
- Check keyboard inspection, explanatory text and the supported route for correcting a fixed value.
Use the accessible forms guide for that last review. Finish when the role, request representation and accepted record agree. These are proposed checks, not evidence that the fictional form or a reader’s implementation has been tested.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: the disabled attributeChecked Disabled native controls do not participate in submission or constraint validation and cannot receive focus.
Limits: A fieldset can disable descendants; visual styling alone does not establish the state. - MDN: the readonly attributeChecked Supported readonly controls remain focusable and can be submitted, while bypassing constraint validation.
Limits: Readonly does not apply to select, checkbox or radio; other eligibility conditions still matter. - MDN: FormData constructorChecked FormData(form) uses named eligible controls, excludes disabled fields and can be modified by script.
Limits: Constructing FormData does not send it; the application may build a different request.