Glossary · Accessibility term
Semantic HTML
Semantic HTML means using HTML elements for what they mean rather than for how they look. A <button> for something that acts, <nav> for navigation, <h2> for a heading, <table> for tabular data. Those semantics are what assistive technology reads. Where the element is a control, the native one arrives with four things already correct. A role, keyboard behavior, focus participation, and state reported to the platform. Structural elements bring the first of those and none of the rest, because a heading was never meant to be operated. Rebuild a control out of <div>s and you owe all four by hand. An ARIA role changes what the accessibility tree says the element is and changes nothing else, so none of the work the browser was doing for you comes back with it. That is why so many expensive ARIA repairs turn out to be undoing a decision made in the markup.
In practice
A <div> has none of those four, which is why rebuilding a button out of divs means rebuilding all four by hand and getting all four right. ARIA does not help as much as people assume, because a role says what kind of thing this is and nothing more. It does not make Enter work, and it does not supply a name either, which is a separate property with its own rules.
The first rule the standards body states is to prefer the native element, and it names three honest exceptions rather than pretending there are none. The feature exists in HTML but is not implemented, or is implemented without assistive technology support. The visual design rules it out, because the native element cannot be styled the way the design requires. Or the feature is not in HTML at all. The middle one is why most custom components exist, and saying so out loud is more persuasive than insisting it never applies.
There is one thing a native element does not give you, and it is the one people assume it does. A name. An empty <button></button> has a correct role, correct keyboard behavior and no accessible name whatsoever, so it announces as "button" and nothing more. Words inside the element, or a real label on an input, are still your job.
This argument still has far to travel. On the top million home pages in February 2026, fewer than half had a main element or main landmark, and about four in ten skipped heading levels. The number of level-six headings more than doubled in a year, and almost all of those pages skipped levels too. The researchers offer the obvious reading, that h6 is being picked for its size rather than its place in an outline, and offer it as a likely explanation rather than a finding. Worth checking on your own pages, where you can simply look.
Why it matters
It is among the cheapest accessibility work there is, and it is not extra work at all. Choosing the right element costs nothing at the time and removes whole categories of failure before they exist. The numbers point the same way. Pages using ARIA in early 2026 averaged 59 detected errors against 42 for pages without it, and while those pages were also more complex, the narrower measurement is harder to explain away. Of the home pages carrying an ARIA menu, 22% of those menus introduced barriers, missing the markup and the interactions the role commits you to.
The rule of thumb
If you are adding ARIA to explain what an element is, there is usually a native element that would have said it for you, and would have brought the keyboard handling along free. The exception is real and it is narrow. Check whether the design constraint is genuine before you accept it as one.
Where this shows up on the site
Related terms
- ARIAARIA is a set of attributes that tell assistive technology what a custom control is and what state it is in.
- RoleA role is what kind of thing an element is, as reported to assistive technology.
- Heading structureHeading structure is the h1 to h6 outline of a page, and for screen reader users it is the map.
- LandmarkA landmark is a named region of a page that assistive technology can list and jump straight to, and there are eight of them.
- Programmatically determinedProgrammatically determined is WCAG's term for information software can read out of the code rather than infer from how the page looks.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.