a11y freedom beaver

by Steve Faulkner published on Dec 10, 2025

Skip to comments

♿☮️🦫 sez: Know your Standards

1st Rule of ARIA

The first rule originally appeared in 2012 Notes on using ARIA, it was then moved to a new home Using ARIA.

It's not really a rule in any formal sense; I just made it up. It has remained unchanged for 14 years but remains relevant today.

First Rule of ARIA Use

If you can use a native HTML element HTML or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Under what circumstances may this not be possible?

• If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not
• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required
• If the feature is not currently available in HTML

source: Using ARIA

Reasons to be cheerful (about not having to use ARIA so much)

the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not

When I first wrote the first rule there were many new features in HTML, many of which had not had their accessibility support (or support in general) wired up. Which is why I started documenting support for new features back in 2010 (HTML5Accessibility.com WayBack Machine snapshot October 2010). Last time I checked back in August 2020, things were looking much better. So these days there is little to no need to use ARIA to supplement native HTML semantics, the browsers do it for you mostly. In fact the unecessary use of ARIA is a HTML conformance error as defined in the ARIA in HTML specification.

visual design constraints rule out the use of a particular native element, because the element cannot be styled as required

In 2025 the opportunity for a front end developer to craft visual UI that meets the needs of their bosses is much improved. CSS and browser implementations continue to be enhanced to make it possible.

the feature is not currently available in HTML

This is still a valid reason for building stuff from HTML elements that carry little or no semantics, then adding ARIA to convey meaning robustly and interoperably to people that make use of assistive technology to render web content understandable. But valid less so as many of the features that are routinely foisted upon users are now available as native HTML, for example, dialogs and disclosures

What ARIA does not do

The good thing about using HTML elements is they have operability built in: ARIA does not.
For example, a <button>-element is automatically included in the focus order and will have event listeners attached, an element with role="button" will not have those characteristics by default.
Please read What ARIA still does not do for details.
A popular use case for ARIA is custom elements, to appreciate what you need to do to make them accessible, the Web Components punch list may be helpful.

Last words

We already know:

Increased ARIA usage on pages was associated with higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected.

Do not introduce more ARIA into your code in an effort to please the knowledge ghouls of OpenAI and their new browser. Although you wouldn't know it from the bumpf OpenAI published - It is not needed.

and a merry fucking xmas to all!

About Steve Faulkner

Accessibility is Political.
I have done stuff on the web for a period of time, some of which I am pleased with.
I also sell Web Standards leisurewear.

HTML Accessibility: HTML Accessibility