Inspect the working example
The fieldset is disabled. Its first legend contains a checkbox, while a text field sits outside that legend. The checkbox is an isolated native example: toggling it does not enable the text field or perform another action.
| Case | Input or inspection | Result and meaning |
|---|---|---|
| Legend descendant | Inspect legend-check :enabled | True; it can be toggled |
| Outside control | Inspect note :disabled | True; fieldset disabled state applies |
| Own property | Read note.disabled | False, because the input itself lacks the disabled attribute |
Follow the browser mechanism
A disabled fieldset disables relevant descendants except those inside its first legend. An input’s disabled property reflects its own attribute; :disabled tests effective disabled state, including this inheritance. Do not infer editability from the property alone.
A second legend does not get the first-legend exception
The counterexample keeps a first legend and puts the checkbox in a second legend. Only the first legend descendant exception is defined for the disabled fieldset.
<fieldset disabled><legend>First legend</legend><legend><label><input id="legend-check" type="checkbox">Second legend checkbox</label></legend><label>Sample note <input id="note" value="Fixed sample"></label></fieldset>The checkbox now matches :disabled and cannot be toggled by the user. This malformed extra-legend example illustrates the first-legend boundary; use one legend in the actual fieldset.
Try the repair
The text input has disabled=false in its own property. Is that sufficient evidence that a user can edit it here?
Show the worked answer
No. Its containing fieldset is disabled and the input is outside the first legend. Check :disabled and the actual interaction; the effective state is disabled.
- Record own attribute/property and effective selector state separately.
- Toggling the legend checkbox must leave the disabled text field disabled.