What this check examines
This check focuses on interactions that can appear correct while their underlying contract is broken. A visible word beside an input is not necessarily its label. A form value visible on screen is not necessarily submitted. A button-like style does not automatically provide keyboard behavior. Each question asks you to separate those layers.
Review the forms, form-accessibility, and disclosure lessons first. When deciding between answers, prefer the native element that matches the task and ask which relationships the browser can infer from the source. Treat ARIA as a way to communicate missing semantics, not as a mechanism that implements event handling.
After checking your answers, build a two-field form and operate it without a pointer. Observe a required-field error, then inspect the submitted FormData entries in a controlled local example. Compare disabled and readonly on a supported text input. Finally, remove the stylesheet and see whether the control names and reading sequence still make sense. These exercises connect the conceptual answers to behavior that a static screenshot cannot show.
Reason through the choices
Turn the result into practice
Revisit each explanation you missed. Write a small counterexample that demonstrates why the tempting answer fails, then compare the source, parsed tree, and behavior. You can revise your answers and check again; scores stay on this device when storage is available.
Review the related lesson · Inspect a document · Try a coding challenge