Native HTML Before ARIA in a Website Redesign

A website redesign is often when accessibility work gets “added.” The new component library arrives with menus, toggles, and accordions, and each one gets a layer of ARIA attributes so it will pass an audit. The intent is good. The results, measured across a million home pages, are mixed.

ARIA (Accessible Rich Internet Applications) is a W3C specification for adding roles, states, and properties that tell assistive technologies, such as screen readers, what an element is and what condition it’s in. Used where HTML has no built-in equivalent, it fills real gaps. Used in place of HTML that already does the job, it tends to add work and errors. This article looks at what the 2026 WebAIM Million shows, what W3C guidance says about the mechanism, and how to apply both during a service-site redesign.

---

What the WebAIM Million measured in 2026

WebAIM, based at Utah State University, runs the WAVE accessibility engine against the home pages of the top 1,000,000 websites each year. The 2026 report uses data from February 2026 and covers the rendered page after scripts and styles have run.

Several of its figures matter for redesign planning:

• Errors are rising. Home pages averaged 56.1 detected errors, up 10.1% from 51 in 2025. 95.9% of pages had detected WCAG 2 failures, up from 94.8%. That reversed six years of small improvements.
• Pages are heavier. The average home page had 1,437 elements, a 14.3% increase in one year.
• ARIA use is climbing quickly. WebAIM counted more than 133 ARIA attributes per page on average, 27% more than a year earlier and over six times the 2019 level. 82.7% of home pages used ARIA beyond landmark roles.
• More ARIA, more detected errors. Pages with ARIA averaged 59.1 detected errors. Pages without it averaged 42.

WebAIM is careful about that last comparison, and so should we be. Pages with ARIA were also more complex, and the report says the correlation “does not necessarily mean that ARIA introduced these errors.” It is an association, not proof of cause. Even so, more ARIA has not come with fewer detected errors.

Some patterns are more specific. 5.7% of home pages used an ARIA menu (role="menu"), and 22% of those menus introduced barriers because they lacked the markup and interactions a menu role requires. Use of aria-hidden="true" averaged 23.3 per page, up 30% from 18 in 2025. Hand-made role="button" elements rose from 3.6 to 4.8 per page.

---

Why ARIA behaves like a promise, not a fix

The W3C ARIA Authoring Practices Guide (APG) opens with a blunt heading: “No ARIA is better than Bad ARIA.” Its first principle explains why. A role is a promise. Writing <div role="button"> tells assistive technology the element is a button, but, as the APG notes, ARIA roles don’t make browsers provide keyboard behavior or styling. The author has to supply all of that in JavaScript, or the promise is broken.

A native <button> carries that behavior already. It’s focusable, it activates from the keyboard, and it reports its role without any extra attributes. A <div> styled to look like a button gets none of this. ARIA can change what the element is announced as, but it can’t add the behavior.

A familiar comparison is a store sign that says “Open.” The sign doesn’t unlock the door. If the door stays locked, the sign makes things worse, because people now trust it. The APG makes a similar point about ARIA’s “cloak”: some attributes override what an element really is. A link given role="menuitem" is announced as a menu item rather than a link. An aria-label replaces the visible link text for assistive-technology users.

The four rules of ARIA use, kept in W3C’s Using ARIA document, turn this into practice:

1. Prefer native HTML. If an HTML element or attribute already has the semantics and behavior you need, use it instead of repurposing another element with ARIA.
2. Don’t change native semantics unless you really have to.
3. Make every interactive ARIA control keyboard-usable. A role="button" element must take focus and activate with both Enter and Space.
4. Never put role="presentation" or aria-hidden="true" on a focusable element. If you do, some users will focus on something that, for them, isn’t there.

One note on sources: W3C published Using ARIA as a Discontinued Draft on 24 February 2026. The four rules are kept “for historical purposes and for easier reference,” and ongoing guidance now lives in the APG. The rules still match the APG’s principles, but cite the APG as the maintained reference.

---

Where redesigns tend to add ARIA debt

Redesigns create a particular risk. Old templates get replaced quickly, often with component kits or generated code. WebAIM’s 2026 conclusion links the rise in complexity to “increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices.” That is WebAIM’s reading of the trend, not a measured cause, but it describes how many redesigns are built.

On a typical service site, the risk tends to show up in a few places:

Component	Common ARIA-heavy build	Native-first alternative	What to verify
Primary navigation	role="menu" with menuitem children	A list of ordinary links (<a href>)	Each link is announced as a link, and Tab moves through them in order
Mobile menu toggle	<div role="button"> with click handler	<button> with aria-expanded	Enter and Space both toggle it, and the state is announced
Icon-only controls	<span> icon with aria-label	<button> or <a> with an accessible name	Name matches the action (“Open menu”, “Contact”)
Hidden or off-screen panels	aria-hidden="true" on a wrapper that still has focusable links	Remove from the tab order or hide with CSS display: none	Keyboard focus never lands on something invisible or silent

In the toggle row, ARIA is still used, but as the APG’s “suspenders” kind: aria-expanded adds state to a real button rather than imitating one. That’s the line to hold. ARIA should describe what HTML can’t, not stand in for elements HTML already has.

The table also connects to two of the six error categories WebAIM finds most often. Empty links (46.3% of home pages) and empty buttons (30.6%) are common on icon-heavy designs where the control has no text and no accessible name. WebAIM reports that those six categories account for 96% of all detected errors, and they’ve been the same for seven years.

---

A native-first review for the redesign build

Run this review on the component library before page templates are approved:

• List every interactive component and note which element it’s built on.
• Replace clickable <div> and <span> elements with <button> (for actions) or <a href> (for navigation).
• Remove role="menu" from site navigation unless the component really implements the full menu pattern, keyboard behavior included.
• Search the codebase for aria-hidden="true" and check that no focusable element sits inside it.
• Give every icon-only link and button an accessible name that states its purpose.
• For any ARIA role you keep, test keyboard operation and at least one screen reader and browser combination. The APG says this interoperability testing is essential before production.
• Re-run an automated checker on the new templates, and remember WebAIM’s caveat: no detected errors doesn’t mean a page is accessible.

---

Limits of the evidence

The WebAIM Million covers home pages only and relies on automated detection, which WebAIM says can’t catch every conformance failure. Its ARIA comparison is correlational and mixed up with page complexity. W3C’s Using ARIA is informative guidance, not a conformance requirement. The APG also notes that some ARIA features have no mobile browser support, and that touch interaction patterns aren’t standardized yet.

There are also legitimate reasons to use ARIA. Using ARIA lists them: the HTML feature doesn’t exist, isn’t supported by browsers or assistive technology, or can’t be styled the way the design requires. Native-first is a default, not a ban. Custom tabs, comboboxes, or live updates may need ARIA. They also need the matching behavior and testing.

---

Practical takeaways for your next website

1. Audit components, not just pages. Errors in a shared header or menu repeat on every template, so fix them once at the source.
2. Use the element that already works. Buttons for actions and links for navigation are the most reliable defaults HTML offers.
3. Treat each ARIA role as a commitment. If you can’t build the keyboard behavior and test it, don’t add the role.
4. Keep complexity in check. WebAIM’s data tie rising errors to heavier pages, so fewer components and fewer wrappers mean less to get wrong.
5. Measure after launch. Compare automated results and manual keyboard checks before and after the redesign so improvements are verified, not assumed.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help rebuild your components on solid HTML foundations so accessibility holds up after launch.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].