Native semantic elements bring assistive-technology behavior with them

What it is

Choosing a platform semantic element — button, a, input, headings on the web; Button, TextField, Switch on native — also chooses a wired bundle of assistive-technology behavior: the control shows up in the matching list, keyboard or equivalent activation works, and a screen reader announces it as that kind of control. Picking the element is borrowing that mapping, not picking a look.

A painted rectangle can look like a button and sit outside the mapping. Appearance can be restyled. Behavior travels with the element type. This card is only “the right type brings the behavior.” It is not how to reconstruct a control from a generic box.

Why it happens

Browsers and OS toolkits map semantic elements into the accessibility tree, then out to platform assistive APIs. A <button> is in the tab order by default, Space and Enter activate it, and a screen reader calls it a button; <a href> joins the link list; <h2> joins heading jumps. Specifying those elements is a reservation for that bundle; the file does not have to restate “focusable, activatable, listed as a button.”

A <div>, an un-roled View, a sliced image used as a button, never enter that mapping. A click handler can be attached, and the screen reader still treats a static region, the keyboard may never land, and the button, link, and heading lists stay empty. Behavior is not a side effect of style. It is the element type’s registration on the accessibility tree. Changing type changes the registration; changing skin does not.

Where it stops holding

A native element with empty content — a button with no name, a link with no href, an empty heading — still registers, but as an object nobody can identify, which is harder to debug than the wrong type. Canvas, game engines, and custom drawing surfaces have no native control tree, so “pick a semantic element” is not a path; they need a different exposure API. A native element wrapped in an opaque custom layer can be blocked from the mapping: the spec says button, AT still sees nothing. Decorative surfaces that must not be interactive should not be made into buttons “to get the behavior for free”; that is the wrong behavior.

Applying it

• On the spec and in the component inventory, name the element type (button, link, heading, input, switch) before the look. Actions the platform control can do are not specified as generic boxes.
• In review, open the screen reader’s button, link, and heading lists and check that objects which look like those things appear on the matching list.
• Walk the main path with the keyboard only: each primary action should activate without a mouse first lighting it up.
• How to check: reach the same action with a mouse, with Tab, and from the screen-reader control list. A miss on any of the three is a look without the native bundle.

Related

• Same group: R3.01.2 Faking a control with a generic box requires filling in all of its semantics · R3.01.3 Structural order is the order assistive technology walks
• Nearby: J2.09 Semantic structure · R3.09 Semantic structure and accessibility implementation
• Search terms: native element accessibility · built-in AT behavior · semantic HTML controls