Semantic HTML and ARIA roles

What it means

Semantics describe what a control is; interaction behavior determines how you reach and operate it. Those responsibilities must agree. A control can be presented as a button without providing the keyboard path that a button user expects.

This comparison focuses on button actions, not every HTML element or ARIA pattern. The important distinction is between behavior supplied by the native element and behavior that an author must implement for a custom control.

Try it

Simulation: start with Element = button and Custom focus and keyboard handling implemented? = no. Change only Element to div role=button, then inspect the result and its explanation. Use Compare with baseline to display the native-button outcome beside the current outcome. Changing an input clears the previous comparison; Reset returns to the initial inputs.

Keyboard action path modeled. A native button supplies standard activation and focus semantics.

Keep Custom focus and keyboard handling implemented? = no for the first comparison. Here, no means that no custom implementation is asserted; it does not switch off a native button's built-in behavior.

Reset restores Element = button and Custom focus and keyboard handling implemented? = no, removes input errors, and clears the comparison. It preserves your independent choices to open or close FAQ answers and About this model.

How it works

A keyboard interaction needs more than a declared role. You must be able to move focus to the control, then use its expected keys to invoke its action. If either link is missing, communicating “button” does not supply the missing behavior.

A native button supplies standard focus and activation behavior. A div with role=button communicates an intended control type, but the author must supply the corresponding focus and keyboard implementation. The WAI-ARIA APG button pattern's Keyboard interaction section describes the Enter and Space expectations; its keyboard-interface guidance addresses tab sequence and predictable focus.

The simulation represents this distinction with two branches. For Element = button, native behavior supplies the modeled path. For Element = div role=button, the path depends on whether custom handling is asserted present. The model does not inspect the implementation behind that assertion. Its result therefore demonstrates where behavior must come from, not whether a real control passes testing.

Worked example

This is a synthetic baseline, not a captured browser observation.

The result is Keyboard action path modeled. The explanation is: “A native button supplies standard activation and focus semantics.”

The model takes the native-element branch, so the absence of custom handling does not create a missing keyboard path. Changing the custom-handling answer while keeping Element = button would not change this modeled outcome: the native element, rather than that assertion, supplies the behavior. This does not establish that the button's name, styling, states, or surrounding page interaction are correct.

What changes when the condition changes

Change only Element to div role=button. Keep Custom focus and keyboard handling implemented? = no.

The result becomes Keyboard path absent. The explanation is: “ARIA role alone does not make a div keyboard operable.” The intended button role remains, but neither a native button's behavior nor an asserted custom implementation supplies the keyboard path.

Now keep Element = div role=button and change Custom focus and keyboard handling implemented? to yes. The result becomes Keyboard action path modeled, with the explanation: “The custom role needs explicit focus and keyboard behavior, here asserted present.” This is not a rule that custom buttons can never work. It shows that their behavior must come from an implementation beyond the role attribute—and this model accepts your assertion without testing that implementation.

In practice

For a button action, start with the native element rather than recreating its behavior on a generic element. A necessary custom control carries additional focus and keyboard responsibilities; more ARIA does not implement those responsibilities.

To examine an existing control, use a development or staging page you are authorized to inspect. First perform read-only inspection of one specific control: its element, declared role, accessible name, and documented action. Do not activate an unfamiliar production control merely to test accessibility. STOP before activation if its effect, your permission, or the test environment is unclear.

For a harmless control you are authorized to exercise, check the following in the actual page:

• For an ordinary enabled button, keyboard navigation should reach it and show where focus is.
• Enter and Space should each invoke the intended button action. Check both paths, not just pointer clicking.
• Inspect the exposed name and role, relevant states, and where focus goes after the action.

If an observation differs, stop treating the control as verified and record the specific mismatch. A screenshot, a role attribute, and this simulation's positive result cannot resolve it. These are inspection and bounded test steps, not instructions to edit or deploy a replacement control.

Limits and unknowns

No screen reader or browser action test is performed. The simulation evaluates only the supplied synthetic choices; it does not observe your actual control.

The custom-handling input bundles focus and keyboard work into one yes/no assertion. It cannot distinguish a control that supports Enter but not Space, has an incorrect focus destination, or mishandles a state change. If those details have not been observed, real-world operability remains unknown even when the result says Keyboard action path modeled.

The supported selections produce a modeled outcome, not a diagnostic verdict about a real page. If an input is invalid, the shared lab removes the calculated outcome until you correct the input or use Reset; a previous valid result must not be read as applying to invalid input.

Without JavaScript, the initial example and explanation remain readable, but the interactive controls are unavailable. No live accessibility check is implied.

What to carry forward

Use a declared role to decide which behavior to test, not to decide that testing has passed. For a button, useful evidence is whether you can reach it, identify its action, and activate it with the expected keys in its actual context.