HTML Accessibility and ARIA Authoring

Intermediate

HTML already carries accessibility semantics through its native elements. This lesson explains the cross-cutting authoring rules for accessibility and ARIA: when native HTML is enough, when ARIA can supplement it, how roles and aria-* attributes are constrained, and how accessible names and relationships are authored. Element lessons remain responsible for the accessibility behavior of their own elements.

Start with native HTML semantics

A native button, link, heading, list, form control, table, dialog, or other semantic element already communicates meaning to the browser. ARIA does not make a generic element equivalent in every respect to a native control. Start by choosing the HTML element whose built-in semantics match the content or interaction.

<!-- choose the authoring rule -->?

Roles describe semantics; they do not create behavior

The role attribute can expose a semantic role when ARIA in HTML permits that use, but a role does not automatically supply the keyboard interaction, state management, focus behavior, or other native behavior of an HTML control. A custom widget therefore needs substantially more than a role attribute.

<!-- choose the authoring rule -->?

States and properties must match the real UI

ARIA states and properties communicate information such as expanded state, selection, pressed state, current value, invalidity, relationships, and descriptions. The value must describe the actual state of the interface. Do not add an ARIA state merely because its name sounds related to the UI.

<!-- choose the authoring rule -->?

Use explicit relationships when they express the intended connection

ARIA relationship attributes can connect one element to another by ID. Common authoring patterns include aria-labelledby for a visible naming element, aria-describedby for supporting description, and aria-controls for a controlled region. These relationships do not replace the underlying HTML structure when native structure already expresses the relationship.

<!-- choose the authoring rule -->?

Accessible names come from the naming model, not from decorative text

Interactive controls and other nameable objects need an accessible name when their semantics require one. HTML often supplies the best naming mechanism: visible button text, label elements, headings, or element-specific labeling. ARIA naming mechanisms can supplement that model where appropriate, but authors should not create conflicting names or hide meaningful text from the accessibility tree merely to satisfy a checklist.

<!-- choose the authoring rule -->?

Do not create competing or contradictory semantics

ARIA can change or supplement the semantics exposed by HTML only where the relevant authoring rules permit it. An inappropriate role or state can produce a mismatch between what the source says, what the browser implements, and what assistive technology receives. The HTML element and its native behavior remain the starting point.

<!-- choose the authoring rule -->?

ARIA in HTML defines authoring conformance rules

The ARIA in HTML specification is the bridge between WAI-ARIA and HTML authoring. It defines which ARIA roles and attributes are conforming on HTML elements and records restrictions where native HTML semantics take precedence. Therefore, learning ARIA in an HTML course requires checking the HTML-specific ARIA rules rather than assuming that every role is interchangeable on every element.

<!-- choose the authoring rule -->?

Do not replace equivalent native HTML semantics with ARIA

WAI-ARIA explicitly says it is intended to supplement native language semantics. If an HTML feature provides an equivalent role, state, or property, use the HTML feature. This keeps the document understandable as HTML and preserves the browser behavior supplied by the host language.

<!-- choose the authoring rule -->?

Custom widgets have a larger responsibility

When no suitable native HTML control exists, ARIA can help describe a custom interface. But the author must still implement the interaction model: focus management, keyboard behavior, state changes, labeling, relationships, and appropriate DOM updates. ARIA describes the semantics; it does not implement the widget.

<!-- choose the authoring rule -->?

Author conformance and implementation behavior are different questions

An author asks whether markup conforms to HTML and ARIA authoring requirements. A browser and assistive technology stack asks how that conforming markup is exposed through accessibility APIs and presented to a user. Foxipa HTML lessons teach the authoring side here; platform accessibility API mappings and assistive-technology implementation details belong to later platform-oriented material.

<!-- choose the authoring rule -->?

Keep accessibility details with the element that owns them

This lesson does not replace the accessibility sections in button, input, form, dialog, select, table, image, media, and other element lessons. Those lessons explain the semantics and accessibility consequences of their own elements. This lesson owns the cross-element rules for native-first authoring, ARIA roles/states/properties, naming and relationships, and ARIA-in-HTML conformance.

<!-- choose the authoring rule -->?

A practical authoring checklist

Before adding ARIA to HTML, ask: Does a native element already express the meaning? Is the proposed role or aria-* attribute permitted on this HTML element? Does the state or property match the real interface state? Is the accessible name supplied by the appropriate native naming mechanism? Do referenced IDs resolve to the intended elements? If the widget is custom, have its focus and interaction behavior also been implemented?

<!-- choose the authoring rule -->?

What this lesson does not own

This lesson does not teach individual element semantics, DOM event APIs, accessibility API mappings, assistive-technology behavior, WCAG conformance, CSS presentation, or a complete widget-pattern library. Those concerns remain with their appropriate specifications and curriculum domains. WAI-ARIA Authoring Practices can inform widget design later, but it is not being treated here as the normative HTML authoring authority.