ARIA (Accessible Rich Internet Applications)

Why this matters

Modern websites and web applications often include custom components that do not use standard HTML elements. A screen reader can automatically understand a native <button> element, but a custom-built control may need additional information to communicate its purpose, name, and state.

When ARIA is missing or misused, people with disabilities may not be able to use important features at all. This can affect screen reader users, keyboard-only users, people using voice input, and users who rely on predictable, consistent interactions.

Under ADA Title II, UGA must ensure that its digital services are accessible to individuals with disabilities. When custom components are not coded accessibly, they can create barriers that prevent users from completing tasks, finding information, or participating fully in University services.

Back to top

What is ARIA?

ARIA is a set of HTML attributes that help communicate meaning and behavior to assistive technologies. ARIA can define what an element is, describe its current state, and provide additional information that may not be available through visible text alone.

ARIA does not change how something looks visually. It also does not automatically make a component keyboard accessible or fully usable. ARIA only communicates information. Developers still need to provide correct structure, behavior, focus management, and keyboard support.

ARIA is part of the W3C accessibility ecosystem and supports the broader goal of meeting WCAG 2.1 AA expectations through semantic, usable, and testable interfaces.

Before you use ARIA

Before adding ARIA to a component, pause and ask a few key questions. In many cases, native HTML is the better and simpler solution.

• Can I use a native HTML element instead?
• Does this component already exist in a trusted framework or design system?
• Will it work with a keyboard alone?
• Can I test it with a screen reader?
• Am I adding ARIA to support users, or to patch over poor HTML choices?

If native HTML can solve the problem, use native HTML. If a custom component is necessary, ARIA may help, but only when it is paired with proper behavior and testing.

Back to top

The First Rule of ARIA

If you can build it with native HTML, use native HTML.

Native HTML elements already include built-in meaning and expected behavior. A native <button> is focusable, keyboard operable, and announced correctly by assistive technologies. A native <a> works as a link. A native <input> works as a form field.

ARIA is not a replacement for semantic HTML. It is a supplement for cases where native HTML alone cannot express the behavior or relationship users need to understand. Overusing ARIA often creates more work, more confusion, and more accessibility problems.

ARIA roles, states, and properties

ARIA attributes generally fall into three categories. Understanding these categories helps developers choose the right attribute and apply it more responsibly.

Roles

Roles define what an element is. They tell assistive technologies what kind of component users are interacting with.

Examples: role="dialog", role="navigation", role="status"

States

States describe the current condition of an element. They often change as users interact with the interface.

Examples: aria-expanded="true", aria-selected="false", aria-checked="true"

Properties

Properties provide additional information about an element, such as its label, description, or relationship to other content.

Examples: aria-label="Close dialog", aria-describedby="help-text", aria-controls="menu"

These attributes can improve accessibility when used correctly, but they do not replace the need for semantic structure, visible labels, and keyboard support.

Back to top

Common ARIA patterns

Some ARIA attributes appear frequently in modern web interfaces. The examples below describe common use cases and when they may be helpful.

aria-label

Use aria-label to provide an accessible name when visible text is not available or is not sufficient. This is common for icon-only controls.

Example: a close button that only shows an “X” icon might use aria-label="Close dialog".

aria-describedby

Use aria-describedby to connect an element to additional explanatory text, such as instructions, help text, or error details.

Example: an email field may reference helper text that says, “Enter your UGA email address ending in @uga.edu.”

aria-expanded

Use aria-expanded on a control that opens and closes content, such as an accordion header or menu button.

Example: a disclosure button starts with aria-expanded="false" and updates to aria-expanded="true" when the associated panel opens.

aria-controls

Use aria-controls to identify the element controlled by another element, such as a button that opens a menu or panel.

This can help communicate relationships, but it should be used thoughtfully and only when it reflects actual behavior.

aria-hidden

Use aria-hidden="true" to remove purely decorative or redundant content from the accessibility tree.

Example: a decorative icon next to a heading may be hidden from screen readers if it adds no useful meaning.

Never use aria-hidden="true" on something that can receive keyboard focus.

Live regions

Live regions let screen readers announce content changes that happen without a full page refresh.

Use aria-live="polite" for non-urgent updates, such as a confirmation message. Use aria-live="assertive" more sparingly for urgent messages that require immediate attention.

Good and bad examples

The examples below show a common pattern: developers often add ARIA where native HTML would have been the better choice from the start.

Buttons

Do not do this:

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

Do this instead:

<button>Submit</button>

A native button already includes the expected semantics and keyboard behavior.

Navigation

Do not do this:

<div role="navigation">...</div>

Do this instead:

<nav>...</nav>

Native landmark elements are usually clearer and simpler.

Icon-only controls

Do not do this:

<span aria-label="Close">×</span>

Do this instead:

<button aria-label="Close dialog">×</button>

The accessible name should be applied to a real interactive element, not to static text pretending to be one.

Expandable content

Better pattern:

<button aria-expanded="false" aria-controls="faq-answer-1">
  What is ARIA?
</button>

<div id="faq-answer-1" hidden>
  ARIA is a set of attributes that can improve accessibility for custom components.
</div>

In this pattern, the button controls the visibility of related content, and the expanded state updates as the user interacts.

Back to top

How to test ARIA

ARIA should never be added without testing. A component that looks correct may still fail for users who rely on assistive technology.

• Navigate using only a keyboard, including Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate.
• Make sure focus moves logically and remains visible at all times.
• Use a screen reader such as NVDA, JAWS, or VoiceOver to check names, roles, states, and announcements.
• Verify that state changes such as expanded, collapsed, selected, or checked are announced correctly.
• Check that instructions, errors, and confirmations are available to assistive technology users.

If a custom component is difficult to test or difficult to explain, that may be a sign that the pattern should be simplified.

When ARIA goes wrong

Misused ARIA can make accessibility worse, not better. In some cases, it creates barriers that are harder to detect because the interface appears to be accessible on the surface.

• ARIA without keyboard support: A screen reader may announce a control as a button or menu, but keyboard users still cannot operate it.
• Incorrect state management: If aria-expanded, aria-selected, or aria-checked is not updated when the interface changes, assistive technologies receive inaccurate information.
• Misapplied roles: Adding role="button" to a non-button element without the correct behavior creates confusion and inconsistency.
• Overuse of aria-hidden: Hiding meaningful content from assistive technologies can create a different and incomplete experience.
• Redundant labeling: Adding ARIA labels where native labels already exist can result in duplicate or confusing announcements.

ARIA is a power tool. It can improve accessibility when used carefully, but it can also create serious barriers when added without understanding, behavior, or testing.

Back to top

Common mistakes to avoid

• Using ARIA instead of native HTML: Choose <button> instead of <div role=”button”>, and <nav> instead of <div role=”navigation”>.
• Adding ARIA too early: Build the component with semantic HTML first, then add ARIA only if needed.
• Forgetting keyboard support: Every interactive component must be operable without a mouse.
• Failing to update states: ARIA states must stay in sync with what users see and do.
• Using aria-hidden on focusable content: Never hide something from assistive technologies if keyboard users can still reach it.
• Assuming ARIA alone makes something accessible: ARIA supports accessibility, but it does not create full usability by itself.

Related DASH resources

• Forms
• Keyboard Accessibility
• Page Regions
• Links and Buttons
• Navigation
• Popups

Getting help

UGA’s Digital Accessibility Services Hub (DASH) is here to support you. Whether you need help understanding a pattern, troubleshooting a component, or planning a more accessible implementation, our team can help.

• Contact DASH at [email protected] for consultations, training, or technical assistance.

Accessibility is a shared responsibility, and thoughtful development choices make UGA’s digital environment more usable and inclusive for everyone.