ARIA, and the first rule about using it

What problem it was built for

Browsers understand a fixed set of elements. A link, a button, a checkbox, a heading. Each one announces itself to assistive technology without anybody doing anything.

Modern interfaces invented controls the web never had. Tab strips, accordions, sliders, combo boxes. Those are usually assembled from generic elements with scripting attached.

To a screen reader, that assembly is a shape with no meaning. ARIA is the vocabulary for saying this thing is a tab, it is currently selected, and it controls that panel.

The specification exists because the web outgrew its own vocabulary. Browsers understand a fixed set of elements, and interfaces kept inventing controls that set had no word for.

The first rule is to avoid it

The guidance from the people who wrote the specification is blunt. If a native element will do the job, use the native element rather than rebuilding it and labelling the rebuild.

A real button is focusable, operable by keyboard, announced correctly and styled however you like. A generic element dressed up as a button needs several attributes and a scripted keyboard handler to reach the same place.

Most ARIA on small business sites exists because somebody rebuilt something that already existed. Deleting the rebuild is nearly always the better fix.

This is not a rule of thumb somebody invented. It is the first authoring practice in the specification's own guidance, and it is first because ignoring it is the most common way ARIA makes a page worse.

Wrong ARIA is worse than none

This is the part that surprises people. An element with no ARIA is announced by what it actually is. An element with incorrect ARIA is announced as something it is not.

A common example is a label applied to the wrong element, so a reader hears a description that belongs to the control next door. Another is a state attribute that scripting forgets to update, so a menu reports itself as closed while it stands open.

The reader now has confident, wrong information. That is harder to recover from than silence.

The state attributes are where this bites hardest, because they must be kept in step by scripting. A menu that reports itself closed while it stands open is not a small inaccuracy; it is confident, wrong information.

Where it genuinely earns its place

There are real cases. A region whose contents update without a page reload needs to be marked so the update is announced. An icon button with no visible text needs a label.

Landmarks are the friendliest use. Marking the banner, the navigation, the main content and the footer lets a reader jump straight past the parts repeated on every page.

A search field, a breadcrumb trail, an expandable section. Each of those has a well documented pattern, and following the pattern exactly is the way to get it right.

• Landmarks marking the banner, navigation, main content and footer
• A label on an icon button that carries no visible text
• A region that updates without a page reload, marked so the change is announced
• The expanded or collapsed state of a menu or accordion
• The current page in a navigation list
• A search field, so it is announced as search rather than as a text box

The label that overrides everything

One attribute replaces whatever text an element contains. It is useful on an icon button and dangerous everywhere else.

Applied to a link that already reads see our pricing, it silently replaces those words with whatever the developer typed. Sighted readers see one thing and listeners hear another.

If an element has visible text that already says the right thing, leave it alone. Adding a label there can only make the two disagree.

How to tell whether yours is helping

Turn on the screen reader you already own and operate the control. You are listening for three things: what it says it is, what state it says it is in, and whether that state changes when you use it.

An automated check can spot invalid attribute values and some mismatches. It cannot tell you that a correctly formed label describes the wrong thing.

Every page written by Website Builder Studio is assembled from real elements wherever one exists, and each passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards.

What to do on your own site

Start by finding custom controls. Anything that looks like a button but was built from something else, any tabs, any accordion, any popup.

For each one, ask whether a plain version would serve. A list of questions with the answers underneath needs no ARIA at all, because nothing is being operated.

None of this is legal advice. Where a custom control is genuinely needed, follow a documented pattern rather than inventing attributes, and test it by listening.

Start by finding the custom controls, then ask of each one whether a plain version would serve. A list of questions with answers beneath needs no ARIA at all, and it is covered in buttons and controls.