Locked Form Values: Disabled, Read-Only or Just Displayed as Text?

If a customer must see a value but must not edit it, do not specify only “grey out the field.” Decide whether the value remains part of the form submission, whether it needs to behave like a control and where the authoritative value comes from. Disabled, read-only and ordinary displayed text are not interchangeable implementations.

A fictional service-request form might show the customer's account reference beside an editable description. The reference helps the person check the destination. Its presence on screen does not mean the server should trust whatever reference arrives from the browser.

Disabled values can disappear from native submission

The WHATWG HTML form-entry algorithm skips disabled controls when constructing the entry list. It also has other inclusion rules, such as the control's name and the state of checkboxes. A visible value is therefore not proof that ordinary form submission includes it.

This matters when an edit form temporarily disables a field and the server interprets an absent field as a request to clear stored data. Define what absence means in your application's update contract. Do not let an appearance change accidentally become a data deletion.

The rule concerns native form entry construction. Custom JavaScript can build a different request, so ask the developer to inspect the actual payload your application sends. “HTML leaves it out” is not a complete explanation if your app assembles its own JSON.

Read-only is a different state

The HTML input reference for readonly describes preventing user edits while the control can still function. It distinguishes that state from disabled controls and explains that readonly applies only to suitable text controls, not every kind of input.

For an appropriately named, otherwise eligible text input, making it read-only is not the same entry-list exclusion as disabling it. That may suit a value the user should inspect alongside editable fields. It does not mean every dropdown, checkbox or custom widget can acquire the same behaviour by adding one attribute.

The specification also says that whether text in disabled controls can be selected or copied is not defined there. If staff need to copy a reference, make that a tested requirement rather than promising identical behaviour from disabled fields in every browser.

Sometimes the right field is not a field

For a purely explanatory account name or a calculated summary that the person never edits, ordinary clearly labelled text may be simpler. My recommendation is to choose that presentation deliberately instead of dressing every fact as a disabled input.

State how people find the complete value, including long references, and whether it is selectable. Keep the label and value associated understandably. A screen that is easier to read still needs keyboard and assistive-technology review; replacing controls with text is not a general accessibility certificate.

If a displayed fact needs to be changed elsewhere, explain that route. “Managed by your account administrator” is more helpful than an unexplained pale box that appears broken.

None of these states is an access-control boundary

A person or script can alter a request independently of the visible interface. The server should establish the permitted account, record and operation from the agreed trusted context and authorisation rules. Do not trust an account reference simply because the page rendered it as read-only, disabled or hidden.

Likewise, native validation is not proof that the value is correct. The HTML references exclude disabled controls and read-only inputs from their relevant constraint-validation process. Keep business validation and server checks separate from the browser's input affordance.

These are commissioning requirements, not a claim that a particular existing backend already implements them.

Accept the displayed state and the resulting update

Include cases in the application acceptance criteria where a populated value becomes disabled, stays read-only or is shown as text. For each, compare the screen, actual request and saved result. Missing must not silently mean empty unless that is the explicitly agreed rule.

Test copying when required, keyboard navigation and the explanation for unavailable editing. In an isolated test environment, have the developer submit an altered protected value and demonstrate that the server applies the intended authorisation rule rather than the supplied replacement.

Use synthetic accounts and references. Bring the locked-field list and each value's source of authority to a form or portal project discussion. The useful result is a readable form with a predictable update contract, not merely controls painted grey.

Source scope

WHATWG HTML, read on 26 October 2026, supports native entry-list exclusion, readonly applicability and validation distinctions. Presentation selection, server authority and acceptance cases are recommendations for the commissioned application. No form submission or security test has been executed for this article.