HTML - HTML Accessibility with ARIA Attributes

HTML accessibility ensures that websites and web applications can be used by everyone, including people with disabilities. While HTML provides many built-in semantic elements that improve accessibility, there are situations where additional information is needed to help assistive technologies such as screen readers understand the purpose and behavior of elements. This is where ARIA (Accessible Rich Internet Applications) attributes become useful.

ARIA is a set of attributes that can be added to HTML elements to improve accessibility. It provides additional information about the roles, states, and properties of elements, making it easier for assistive technologies to interpret web content correctly. However, ARIA should only be used when native HTML elements cannot provide the required accessibility features.

What is ARIA?

ARIA stands for Accessible Rich Internet Applications. It is a specification developed by the World Wide Web Consortium (W3C) to make dynamic web content and advanced user interface components more accessible.

ARIA helps assistive technologies understand:

  • The purpose of an element

  • The current state of an element

  • How elements are related to one another

  • How users can interact with them

For example, a custom button created using a <div> element is not recognized as a button by screen readers. By adding an ARIA role, it becomes identifiable as a button.

Example:

<div role="button" tabindex="0">
    Submit
</div>

Although this works, it is generally better to use the native <button> element whenever possible because it already provides accessibility features.

Why Accessibility Matters

Accessible websites provide equal access to information and services for everyone, including people with:

  • Visual impairments

  • Hearing impairments

  • Motor disabilities

  • Cognitive disabilities

  • Temporary injuries

  • Age-related limitations

Benefits of accessible websites include:

  • Better user experience

  • Improved search engine optimization (SEO)

  • Compliance with accessibility laws and standards

  • Increased audience reach

  • Easier navigation for all users

Native HTML vs ARIA

Native HTML elements already include built-in accessibility.

Example:

<button>Save</button>

The browser automatically recognizes this as a button.

Instead of writing:

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

Using the actual <button> element is preferred because it supports keyboard navigation, focus management, and screen readers without additional coding.

The first rule of ARIA is:

"If you can use a native HTML element instead of ARIA, use the native HTML element."

ARIA Roles

ARIA roles describe the purpose of an element.

Syntax:

role="role-name"

Example:

<div role="navigation">
    Navigation Links
</div>

This informs assistive technologies that the division represents navigation.

Common ARIA roles include:

Button

<div role="button">
    Click Me
</div>

Navigation

<nav role="navigation">

Main Content

<main role="main">

Banner

<header role="banner">

Search

<form role="search">

Alert

<div role="alert">
    Invalid Password
</div>

Screen readers immediately announce alerts.

Landmark Roles

Landmark roles help users quickly navigate different sections of a webpage.

Common landmarks include:

Banner

Represents the website header.

<header role="banner">

Navigation

Represents menus.

<nav role="navigation">

Main

Represents the main content.

<main role="main">

Complementary

Represents sidebars.

<aside role="complementary">

Content Information

Represents the footer.

<footer role="contentinfo">

These landmarks allow screen reader users to jump directly to important page sections.

ARIA Labels

Sometimes an element has no visible text.

Example:

<button>
    <img src="search.png">
</button>

A screen reader cannot determine the purpose of the button.

Using ARIA:

<button aria-label="Search">
    <img src="search.png">
</button>

Now the screen reader announces:

"Search button"

aria-labelledby

This attribute associates an element with another element containing descriptive text.

Example:

<h2 id="profileHeading">
    User Profile
</h2>

<section aria-labelledby="profileHeading">
    Profile information
</section>

The screen reader uses the heading as the section's accessible name.

aria-describedby

Provides additional descriptive information.

Example:

<input type="password" aria-describedby="passwordHelp">

<p id="passwordHelp">
    Password must contain at least eight characters.
</p>

The screen reader announces the help text when the input field receives focus.

ARIA States

States indicate changing conditions of an element.

aria-expanded

Used for expandable menus.

<button aria-expanded="false">
    Menu
</button>

When opened:

<button aria-expanded="true">
    Menu
</button>

Screen readers know whether the menu is expanded or collapsed.

aria-hidden

Hides decorative content from assistive technologies.

<span aria-hidden="true">
    ★
</span>

The decorative star is ignored by screen readers.

aria-disabled

Indicates an element is unavailable.

<button aria-disabled="true">
    Submit
</button>

Users are informed that the button cannot currently be used.

ARIA Properties

Properties describe characteristics that usually remain constant.

aria-required

Indicates a required form field.

<input type="text" aria-required="true">

aria-invalid

Indicates invalid user input.

<input type="email" aria-invalid="true">

aria-checked

Used with checkboxes and radio buttons.

<div role="checkbox" aria-checked="true">

Accessible Forms

Forms become more accessible when labels are properly associated with inputs.

Example:

<label for="email">
    Email
</label>

<input
type="email"
id="email">

If additional instructions are needed:

<input
id="email"
aria-describedby="emailHelp">

<p id="emailHelp">
Enter your official email address.
</p>

Accessible Images

Decorative images should be ignored.

<img src="flower.jpg" alt="">

Important images should have meaningful alternative text.

<img src="chart.png" alt="Monthly sales increased by 20 percent">

Accessible Navigation

Navigation menus should use semantic HTML.

Example:

<nav>
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">Courses</a></li>
        <li><a href="#">Contact</a></li>
    </ul>
</nav>

ARIA is generally unnecessary here because the <nav> element already conveys its purpose.

Keyboard Accessibility

Users should be able to navigate the website using only the keyboard.

Guidelines include:

  • Every interactive element should be focusable.

  • Use the Tab key for navigation.

  • Avoid keyboard traps.

  • Ensure visible focus indicators.

  • Support Enter and Space keys where appropriate.

Example:

<button>
    Register
</button>

Native buttons automatically support keyboard interaction.

Common ARIA Mistakes

Avoid these common errors:

  • Using ARIA instead of semantic HTML elements.

  • Adding unnecessary ARIA roles to native elements.

  • Forgetting to update ARIA states when content changes.

  • Using incorrect or invalid ARIA attributes.

  • Hiding important content with aria-hidden="true".

  • Creating inaccessible custom controls without proper keyboard support.

Best Practices for Using ARIA

  • Use semantic HTML elements whenever possible.

  • Apply ARIA only when native HTML cannot achieve the desired accessibility.

  • Always test websites with keyboard navigation.

  • Verify accessibility using screen readers.

  • Keep ARIA attributes updated as the interface changes.

  • Ensure form fields have clear labels and descriptions.

  • Use landmark roles to improve page navigation.

  • Write meaningful aria-label and aria-describedby values.

  • Avoid redundant ARIA attributes on elements that are already accessible.

  • Follow the Web Content Accessibility Guidelines (WCAG) to create inclusive and accessible web experiences.

Conclusion

ARIA attributes play a crucial role in making modern websites accessible to users who rely on assistive technologies. They provide additional information about the purpose, state, and relationships of web elements, helping screen readers and other accessibility tools interpret content accurately. However, ARIA should complement, not replace, semantic HTML. By combining proper HTML structure with appropriate ARIA roles, labels, states, and properties, developers can create websites that are more inclusive, easier to navigate, and accessible to a wider range of users.