Skip to main content

Insight · Semantic HTML & Accessibility

Use ARIA only where native HTML is insufficient

Native HTML elements inherently possess a role and user behavior. ARIA only supplements missing semantics and must not distort the actual function.

For web developers and UX teams, the key aspects of "using ARIA only as a targeted supplement" are "native source element" and "complete interaction pattern." The perspective "native semantics and page structure" shows how these two points work together in practice.

Published: 3 min read · Author:

When is ARIA necessary, and when is a native HTML element the better solution?

ARIA is only used after native elements have been examined because only these provide semantics and standard operation together. If a necessary role or dynamic state remains unclear, the supplement, including keyboard, focus, and state logic, must be fully implemented.

Native Output Element

Test criterion

Native Output Element

No native HTML element exists for task, keyboard behavior, and state that fully represents the required meaning.

Test criterion

Complete Interaction Pattern

Role, name, state, keyboard control, and focus handling are implemented and tested as a cohesive behavior.

  • Robust Assistive Technology Output The component is tested with browsers and assistive technologies instead of deriving its accessibility from valid markup.

Use Case: "Role Mockup"

An accordion can initially only be opened by clicking on a heading. The fix replaces the clickable container with a real button, connects it to the content area, and keeps ARIA expanded in sync; arrow key logic is not implemented because the chosen pattern does not require it.

Complete Interaction Pattern

  1. First, model the specific user task using `button`, `a`, `input`, `details`, or another suitable native element.

  2. Add only the meaning that cannot be expressed natively and fully implement the keyboard, focus, and state logic.

  3. Test the finished component in every state using the keyboard and representative screen reader/browser combinations.

Role dummy

  • Role dummy A `div` is assigned an ARIA role but lacks both the expected keyboard control and reliable state changes.

  • Overridden Semantics Additional attributes modify the already correct native meaning and produce contradictory announcements.

  • Unchecked State Transition aria-expanded or aria-selected remains incorrect after an interaction and reports an outdated state to assistive technologies.

Robust Assistive Technology Output

  • Percentage of custom interactive components for which the missing native alternative and the chosen ARIA pattern are documented.

  • Number of checked states in which role, accessible name, keyboard behavior, and output state remain consistent.

Which questions trigger further checks after "using ARIA only as a targeted supplement"

A suitable in-depth resource is available Writing alt text that describes the image function rather than the image content."How does alt text describe the function of an image instead of just visible details?"

In addition: Avoid JavaScript navigation without true links..

If you want to practically implement "using ARIA only as a targeted supplement," you can refer to Robust Website Systems This focuses on "Native Semantics and Page Structure" and "Native Source Element."

Conclusion: Use ARIA only as a targeted supplement

ARIA can supplement missing semantics, but it cannot repair incomplete interaction behavior. The native element remains the most robust starting point.

Sources and Further Information

These primary sources make the assumptions, system boundaries and test methods for "ARIA should only be used as a targeted supplement" comprehensible.

Key Thesis

First, a suitable native element is used. ARIA is only useful if necessary meaning or states cannot be expressed otherwise and the behavior is fully implemented.

What This Is Not About

The article does not focus on an isolated single measure. It distinguishes between the error patterns "dummy role," "overridden semantics," and "unchecked state change."

What it's about

Three criteria apply to implementation: "native source element," "complete interaction pattern," and "robust assistive technology output." Together, they form the benchmark for testing and release.

More insights

Semantic HTML & Accessibility

Select buttons and links based on function rather than appearance.

"using ARIA only as a targeted supplement" includes, as an independent test step, the question: When is a button and when is a link the semantically correct control element?

Semantic HTML & Accessibility

Ensuring Keyboard Operation for Dropdowns and Mobile Menus

Supplements the principle of "Using ARIA only as a targeted supplement" with a separate decision: How can dropdowns and mobile menus be made fully keyboard-operable?

Insights Overview

All VELUNO Insights at a Glance

Further analyses on Website Systems, digital visibility, and robust working models.

Practical Implications

Native starting point: the starting point for implementation

A component review should trace each ARIA role back to its native alternative and its complete user interface. Any unusual custom implementations will then undergo keyboard and assistive technology testing across all states.