Accessibility prompts: check semantics and control names

Last updated: 5 Oct 202611 min read

tutorial

A visual label is not proof of an accessible name. Supply a DOM or accessibility-tree excerpt and ask the model to compare the visible control with its exposed name, role, value, and state. Prefer native form controls, links, headings, and landmarks because they carry interaction behavior the browser already knows. Custom semantics need runtime checks. The prompt should locate missing or conflicting names, but the reviewer confirms how a real control is announced and operated rather than grading a static HTML fragment in isolation.

Operational case

The Harbor dialog has a visible cross icon with a click handler. Its DOM uses a plain span, so it is absent from the tab sequence and lacks a button role and name. The proposed repair uses a button with a concise 'Close booking dialog' name, then tests the keyboard path and spoken label. The reviewer also checks that the form's pickup-code label points to its input, not merely sits next to it visually.

Control: dialog close icon
Visible purpose: close booking dialog
Observed DOM: span with click handler
Expected: native button; exposed name; keyboard operation
Verify: accessibility tree and live interaction

Performance and review cost

Inspecting N controls is O(N) review work, while fixing a shared component may remove the same defect from many routes. A static scan is inexpensive but cannot prove the component's behavior after state changes. Group duplicate findings by component only after checking that each affected instance has the same cause and repair path.

Common Mistakes

Do not use a clickable span where a button is required.
Do not assume adjacent text labels a field.
Do not add a second conflicting name to a correctly named native control.

Connected lessons

prompt engineering

accessibility review