2026-05-17 · 6 min read

WCAG and ARIA on Government Websites: When It Helps and When It Makes Things Worse

# WCAG and ARIA on Government Websites: When It Helps and When It Makes Things Worse

ARIA — Accessible Rich Internet Applications — is the attribute set that lets HTML communicate custom widget semantics to assistive technology. A <div> acting as a button can become accessible to screen readers with role="button" and the right event handling. A live region that updates dynamically can announce its updates with aria-live.

The problem: ARIA is consistently misused. According to WebAIM's annual analysis, ARIA misuse creates accessibility failures that are harder to detect than missing alt text and often harder to fix because they require understanding both the WCAG standard and the ARIA specification simultaneously. Government sites using third-party CMS systems, portal platforms, and embedded widgets frequently inherit ARIA errors they didn't write and don't know exist.

This post explains the first rule of ARIA, the most common ARIA errors on government sites, and how to evaluate whether your site's ARIA implementation is helping or hurting.

The First Rule of ARIA

The W3C ARIA specification includes a usage note that has become widely known as the "first rule of ARIA":

> "If you can use a native HTML element 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."

This rule exists because native HTML elements have decades of browser and assistive technology support. A <button> element is keyboard-focusable, keyboard-activatable, and announced as a button by every screen reader, with no additional code. A <div role="button"> requires:

• tabindex="0" to make it keyboard-focusable
• A keydown event handler for Enter and Space keys
• The role="button" attribute to announce it as a button
• Manual handling of disabled state with aria-disabled
• Testing across multiple screen reader/browser combinations to verify behavior

The <button> gives you all of that for free. The <div role="button"> gives you a maintenance obligation, a testing obligation, and a failure mode.

Government site developers (and vendors) frequently use <div> or <span> elements for interactive components and add ARIA to compensate. Every time this happens, the implementation is more fragile than using the native element would have been.

The WCAG Criteria That ARIA Relates To

4.1.2 — Name, Role, Value (Level A)

The core criterion for custom widgets. Every user interface component must have a programmatically determinable name (what it's called), role (what it is), and state/value (what its current state is).

For a custom dropdown:

• Name: what does this dropdown control? (aria-label or aria-labelledby)
• Role: role="listbox" with option children role="option"
• State: aria-expanded on the trigger, aria-selected on the current option

Missing any of these makes the component opaque to assistive technology.

4.1.3 — Status Messages (Level AA)

Dynamic content updates must be communicated without requiring focus to move to the updated content. This is implemented with ARIA live regions: aria-live="polite" for updates the user should be informed of but shouldn't interrupt current activity, and role="alert" (which is aria-live="assertive") for urgent updates like error messages.

Government sites commonly miss this on form validation feedback, on search result updates, and on dynamic table filtering.

The Most Common ARIA Errors on Government Sites

1. Redundant ARIA roles

Applying a role to an element that already has that role natively:

```html Submit

Section Title

These don't cause harm by themselves, but they indicate that someone was trying to add accessibility without understanding that semantic HTML already provides it. Where redundant roles appear, there are often also places where they're missing or wrong.

2. ARIA labels that conflict with visible text

The visible label text and the aria-label describe different things:

```html Search

Submit ```

The second case breaks WCAG 2.5.3 (Label in Name) because the accessible name doesn't contain the visible label text. Voice control users who say "click Submit" will not activate the button because the accessible name is "Cancel."

Government sites frequently have this failure in icon buttons where the icon has been given an aria-label that differs from the visible text label added for sighted users.

3. Missing required owned elements

ARIA composite roles require specific child roles. A role="listbox" must contain elements with role="option". A role="tablist" must contain elements with role="tab". A role="grid" must contain role="row" with role="gridcell" children.

Government sites using third-party dropdown libraries or data grid components frequently break these ownership requirements when they customize the component's HTML structure without updating the ARIA role tree.

4. aria-hidden misuse

aria-hidden="true" removes an element from the accessibility tree — screen readers skip it. This is correct for purely decorative elements. It causes failures when:

• Applied to elements that contain focusable content (keyboard users can still focus into hidden elements)
• Applied to the entire main content area while a modal is open, but the modal itself isn't receiving focus
• Applied to icon elements that are the only accessible name for their parent button

``html <!-- This is broken: the button's only content is aria-hidden --> <button> <span aria-hidden="true">✕</span> </button> <!-- Screen reader announces "button" with no name — WCAG 4.1.2 failure --> ``

5. Dynamic content without live regions

Page content that updates dynamically without using live regions or focus management:

``html <!-- User submits search — results update here --> <div id="search-results"> <!-- Dynamically populated --> </div> <!-- No aria-live — screen readers don't know it changed --> ``

The fix: either add aria-live="polite" to the results container, or move focus to the results heading after the update. Government search functionality and filtered data views frequently fail this.

6. aria-expanded without focus management

Navigation menus that use aria-expanded to communicate open/closed state but don't move focus into the submenu when it opens:

``html <button aria-expanded="true" aria-controls="submenu"> Services </button> <ul id="submenu"> <li><a href="/permits">Permits</a></li> <!-- ... --> </ul> ``

This is structurally correct, but if the submenu appears visually below the button and a keyboard user pressing Tab after the button goes to the next item in the DOM rather than into the submenu, the expanded state is visually correct but functionally broken.

When ARIA Is Genuinely Necessary

ARIA is not a problem to avoid — it is a tool for specific situations:

• Custom widgets with no native HTML equivalent: accordions, tabbed interfaces, custom comboboxes, tree views, carousels, data grids
• Dynamic content that needs to announce updates: live search results, form validation feedback, step progress indicators
• Landmark supplementation: when your HTML structure doesn't naturally produce the right landmark pattern, role="main", role="search", and role="complementary" can fill gaps
• Description and labeling: aria-describedby and aria-labelledby connect related elements that can't be connected with native HTML semantics

Getting an ARIA Audit

ARIA failures require manual screen reader testing to detect reliably — automated tools catch some ARIA errors (missing required children, invalid attribute values) but miss the interaction-level failures (focus management, live region coverage, label conflicts discovered in use).

The Parallax WCAG audit from Morton Technology Consulting includes ARIA and custom widget testing as part of the screen reader evaluation component — using NVDA with Chrome to assess live regions, custom widget keyboard interactions, focus management, and accessible name conflicts. ARIA is one of the categories most commonly overlooked in automated-only audits.

The WCAG Pre-Audit Readiness Kit ($149) includes an ARIA review checklist covering the most common error patterns, a list of native HTML elements and their default implicit ARIA roles (so you know when ARIA is redundant), and a screen reader testing guide for manual ARIA evaluation.

---

*Morton Technology Consulting LLC, Tallahassee, FL. WCAG 2.1 ARIA and custom widget accessibility audits for Florida government agencies. [email protected]*

Morton Technology Consulting LLC — WCAG 2.1 AA audits for Florida government agencies. Parallax audit → · WCAG Readiness Kit → · All posts →