Glossary

Semantic HTML

Semantic HTML means using the element whose meaning matches the content — a button for something that acts, a heading for a heading, a list for a list. The practical argument is not tidiness: a native element arrives with keyboard behaviour, focus handling, assistive-technology semantics and platform conventions already implemented. Rebuilding those on a generic element means rebuilding all of them, and the usual outcome is that most get rebuilt and one does not.

What a native button brings that a div does not

It is focusable, so keyboard navigation reaches it without an attribute being added.

It activates on both the enter and space keys, following the platform convention for each.

It is announced with its role, so a screen reader user knows it is actionable before interacting.

It participates in form submission, and it inherits the disabled state's behaviour rather than only its appearance.

Reproducing all of that on a generic element is five pieces of work, and the failure mode is silently omitting one.

What landmarks and headings do

Landmark elements let assistive technology offer a list of regions to jump between, which is how a screen reader user skips repeated navigation.

Headings form an outline that can be navigated directly, which is one of the most used navigation mechanisms after landmarks.

A page built from generic containers has neither, so every visit means traversing the whole document linearly.

The visual design is unaffected: landmarks and headings can be styled to look like anything.

Which makes this one of the few accessibility improvements with no design cost at all.

Why ARIA is a worse substitute than it looks

ARIA supplies semantics and supplies no behaviour: a role on a generic element announces a button and does not make it focusable or operable.

It also overrides what was there, so a wrong role actively replaces correct semantics with incorrect ones.

The widely repeated guidance is that no ARIA is better than bad ARIA, which follows directly from that.

So the order is: use the native element, and reach for ARIA only where no native element expresses what the component does.

Where custom components are still necessary

Patterns the platform does not provide — a combobox with filtering, a tree, a tab set.

Those have documented authoring patterns specifying the roles, states and keyboard interactions each one requires.

Following such a pattern is substantial work, which is the honest reason to check first whether a native element would do.

A native select styled within its limits is frequently a better outcome than a custom listbox implemented at ninety per cent.

How it is observed

Elements made interactive without the semantics that make them reachable are detected, which is the clearest instance of the problem.

The landmark structure of the page is read, as is the heading outline.

ARIA roles, states and properties are validated against the specification, including roles that are invalid on the element carrying them.

Whether a custom component follows its authoring pattern's keyboard behaviour is interaction and is outside a static reading.

Frequently asked questions

Can I make a div behave like a button with ARIA?
ARIA supplies the announcement and none of the behaviour. You would still need focusability, both activation keys and the disabled semantics — which is what the native element already does.
Does semantic markup constrain my design?
Landmarks and headings can be styled to look like anything, so those are free. Native form controls have real styling limits, which is the one place the trade is genuine.
When should I build a custom component?
When no native element expresses what it does. Follow the documented authoring pattern for the roles, states and keyboard behaviour — it is more work than it looks.

Sources

Related

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website