Accessibility, ARIA, and Semantic HTML

Accessibility, ARIA, and Semantic HTML

Summary: Accessibility is not a feature, a checklist, or an optional enhancement. It is the discipline of ensuring that meaning, structure, and behaviour remain usable when visual presentation is removed. This article explains how semantic HTML, ARIA, and backward‑compatible design work together — and why misuse of ARIA often makes accessibility worse, not better.

Context

Accessibility is frequently misunderstood as a niche concern or a regulatory burden. In reality, it is fundamental to how the web works.

Blind users browse the internet every day — independently, professionally, and at speed — using assistive technologies such as screen readers. These tools do not “look” at a page. They interrogate structure, roles, relationships, and behaviour exposed through the browser’s accessibility APIs.

If that structure is missing, misleading, or inconsistent, the experience breaks — regardless of how visually polished the interface may be.

The web was never visual‑first. It was structured first.

Accessibility and Machine‑Readability: The Purpose

Accessibility and machine‑readability are often framed as separate concerns:

• accessibility as a human accommodation
• machine‑readability as an SEO or automation problem

This separation is artificial.

Assistive technologies *are machines acting on behalf of humans*. They rely on predictable, unambiguous structure to translate content into speech, braille, or alternative navigation models.

Machine‑readability exists so that:

• meaning survives translation
• intent is communicated without sight
• interaction remains predictable
• users retain autonomy

If an interface only works when seen, it is incomplete.

Yes — Blind People Browse the Web

This should not be surprising, yet it often is.

Blind users do not consume pages linearly. They:

• jump between headings
• navigate by landmarks
• list links or form controls
• skim structure rather than content
• rely on predictable keyboard behaviour

Screen readers query the accessibility tree generated from:

• native HTML semantics
• ARIA roles, states, and properties
• actual browser behaviour

When those signals are wrong, users are forced to guess. For sighted users, this is inconvenient. For blind users, it can be a hard stop.

What Semantic HTML Really Means

Semantic HTML is not about fashionable tags or modern syntax.

It is about meaning.

Long before HTML5 introduced new element names:

• headings conveyed hierarchy
• lists conveyed grouping
• links conveyed navigation
• forms conveyed interaction
• tables conveyed data relationships

Assistive technologies were built around these concepts — and still rely on them.

Semantics live in:

• structure
• relationships
• behaviour

Not in tag names alone.

A correctly structured document using traditional elements is often more accessible than a visually modern layout with broken or overridden semantics.

A Deliberate Strategy: Backward‑Compatible Semantic HTML with ARIA

A highly effective accessibility strategy is to:

Use a strict, well‑understood subset of HTML4/XHTML features, apply clear semantic structure, and layer ARIA roles only where behaviour genuinely requires it.

This approach prioritises:

• predictable browser behaviour
• stable accessibility API mappings
• broad assistive technology support
• graceful degradation across user agents

Accessibility improves through consistency, not novelty.

Backward compatibility is not a technical compromise — it is an accessibility feature.

Users do not choose:

• their devices
• their operating systems
• their assistive technologies
• their upgrade timelines

Designing for older capabilities is not supporting the past. It is refusing to exclude users in the present.

ARIA: Purpose, Not Decoration

ARIA exists to solve a specific problem:

How do we expose meaning, role, and state when native HTML semantics are insufficient or unavailable?

It was designed for:

• complex widgets (trees, grids, tabsets)
• dynamic state changes
• rich client interfaces where no native element exists

ARIA was not designed to:

• replace semantic HTML
• fix poor structure
• override native behaviour
• decorate generic containers

ARIA describes intent — it does not create it.

The First Rule of ARIA

If you can use a native HTML element, do not use ARIA.

Native elements provide:

• built‑in keyboard interaction
• correct focus management
• reliable accessibility API mappings
• consistent behaviour across platforms

Once a native element is replaced with a generic container and a role, the developer becomes responsible for reproducing *all* of that behaviour.

Most implementations do not.

Common ARIA Misuse Patterns

Div Soup with Roles

<div role="button">Save</div>

This announces as a button, but lacks:

• keyboard activation
• focus handling
• disabled states
• expected interaction cues

It sounds correct — but behaves incorrectly.

Overriding Native Semantics

<button role="link">Read more</button>

Overriding native semantics:

• confuses assistive technologies
• introduces inconsistent behaviour
• provides no functional benefit

If it behaves like a link, use a link. If it behaves like a button, use a button.

Partial ARIA Implementations

ARIA roles are contracts, not labels.

For example, `role="tab"` implies:

• keyboard navigation rules
• selection states
• relationships to a tablist and panels

Applying the role without the full interaction model breaks user expectations.

ARIA as Decoration

Adding ARIA “just in case” introduces noise:

• redundant labels
• duplicated roles
• misleading announcements

Missing information is better than incorrect information.

Why ARIA Misuse Is Worse Than No ARIA

ARIA creates expectations.

When those expectations are broken:

• navigation becomes unpredictable
• trust is lost
• users must relearn every interface

Misleading accessibility signals are more harmful than absent ones.

ARIA that lies about behaviour actively damages usability.

ARIA Is Descriptive, Not Corrective

This is the critical mental model:

ARIA describes what is already true — it does not make it true.

If an element:

• is not keyboard accessible
• does not manage focus
• does not behave correctly

Then adding an ARIA role does not fix it.

It misrepresents it.

Progressive Enhancement and Predictable Behaviour

Progressive enhancement is an accessibility strategy.

By:

• starting with reliable structure
• layering behaviour carefully
• avoiding assumptions about capability

Interfaces remain usable across:

• modern and legacy browsers
• diverse assistive technologies
• constrained environments

Predictability is more important than cleverness.

Design and Architecture Considerations

Good accessibility emerges from early design decisions:

• semantic structure first
• behaviour before appearance
• consistency over novelty

Component libraries, frameworks, and abstractions should:

• honour native behaviour
• avoid unnecessary role overrides
• make accessibility the default, not an add‑on

Accessibility debt compounds quickly — and is expensive to unwind.

Practical Guidance

• Use native HTML elements wherever possible
• Let the browser expose semantics for you
• Introduce ARIA only when:

 * no native element exists
 * behaviour is fully implemented
 * the interaction pattern is well understood

• Test with a keyboard and a screen reader
• Prefer boring, predictable solutions

The Quiet Truth

Most accessibility failures are not caused by lack of ARIA.

They are caused by:

• ignoring structure
• fighting the browser
• prioritising visuals over interaction models

ARIA does not fix that.

Good engineering does.

Related Topics

• Progressive Enhancement
• Structured Data
• UI Controls and Widgets
• Machine‑Readable HTML Technologies