Disabled and Readonly in a Robot Service Intake Form

A service form may show a request reference, a robot identifier and a field for an observed symptom. If the first two fields look locked, a reader still needs to know which HTML behavior is intended. Disabled and readonly are different states, and neither should be used as a complete description of validation, submission or trust. This article proposes a documentation exercise around an entirely fictional intake form. It sends no request, collects no personal data and performs no actual interface test.

Identify the applicable control and state

The HTML disabled-state definition describes how a control becomes disabled, including relevant fieldset rules, and says disabled controls are barred from constraint validation. Looking only for an attribute on the individual input may therefore miss part of the state calculation. A label such as locked is less precise than identifying the actual control and its state.

In the fictional form, the request reference is described as disabled. The proposed review would first locate that description and ask whether it applies to the individual control or through a containing group. The exercise does not inspect a real DOM, and it does not infer what a particular page is doing from a gray background or an icon.

Keep the description distinct from an observation. A supplier may explain intended behavior in a specification while a receiving team has not yet inspected the delivered page. Both materials can be useful, but a handover note should not relabel a design statement as a completed interaction test.

Readonly also has a validation boundary

The HTML readonly definition concerns applicable text controls and prevents user editing. A readonly input is also barred from constraint validation. It is therefore incorrect to say that readonly necessarily remains part of native validity checking while disabled is skipped. That distinction confuses validation with other form behavior.

Readonly does not apply indiscriminately to every control type. A receiving editor should identify the actual type before applying the term to a checkbox, button or another control. The proposed fictional form uses a text identifier, but that choice does not establish how some other delivered form is implemented.

For the exercise, ask what the user is expected to read and which behavior the contributor intends to prevent. Do not turn the attribute name into a guarantee about selecting text, every focus interaction or a complete accessibility outcome. Such observations would need their own appropriate review.

Submission is a separate question

Under the normal HTML entry-list construction rules, disabled controls are omitted. Readonly does not itself exclude an otherwise eligible control from the entry list. Other conditions, including the relevant name and form association, still matter. The term successful constraint is not a useful substitute for these separate rules.

In the fictional form, the editor could ask whether the contributor expects the text identifier to appear in the submission and what establishes that expectation. The request reference might instead be maintained by the server or supplied through another mechanism. Those possibilities should be described if actually present, rather than inferred because a visible field is disabled.

No submission is performed in this article. A proposed expectation based on the standard should remain labeled as such. It does not show that a backend received a value, accepted a request or attached the identifier to the correct service case.

A locked appearance is not an integrity guarantee

Client-side control states do not establish that received information is trustworthy. The disabled-state discussion itself notes that programmatic modifications remain possible. An application needs its own appropriate handling of incoming information; an editor should not describe a readonly identifier as protected merely because ordinary typing is restricted.

For a fictional documentation exchange, the receiving team could ask which system owns the identifier and what the service provider says about the relationship between the visible field and the recorded case. The article supplies no server implementation, security assessment or method for modifying a live request.

The question is about the boundary of the claim. An attribute can describe a user-interface behavior without proving the identity or correctness of a service record. Keeping those statements separate avoids presenting a limited interface description as a broader system assurance.

Write the exercise outcome around actual evidence

A proposed note can have separate places for the declared control state, any observed interaction and the expected submission behavior. If no interaction was observed, leave that part unresolved. If no request was sent, do not write that submission or server validation succeeded. The form described here is fictional and none of those outcomes was tested.

The two original diagrams summarize reading questions and conceptual distinctions. They contain no captured intake form or personal information. Related material is available in the service intake documentation articles and the article directory. A precise note distinguishes editing, validation, entry-list eligibility and backend evidence rather than collapsing them into a single locked label.