WCAG 3.2.4 Consistent Identification: Keeping Similar Components Consistent

WCAG 3.2.4 Consistent Identification: keeping similar components consistent

WCAG 3.2.4 Consistent Identification asks that components with the same purpose or behaviour be identified the same way across a site or app. That includes visible labels, accessible names, roles, states, visuals and keyboard behaviour. Consistency reduces cognitive load and helps assistive technologies present predictable information.

What consistent identification covers

The idea is simple. If two things do the same job they should look and behave the same, and they should be announced the same by assistive tech. Key items to keep consistent:

• Accessible name and role (element type, ARIA role)
• Visual appearance and iconography for equivalent controls
• Keyboard focus and interaction model
• State labels (on, off, selected, error)
• Link and button text that clearly indicates purpose

Why this matters

Users with cognitive disabilities, low vision, or those who rely on screen readers or keyboard only input benefit most. Predictable UI reduces time to task, lowers errors and improves confidence. It also helps support staff and automated testing when components follow consistent rules.

Where inconsistency commonly appears

• Icon-only buttons used sometimes with aria-labels and sometimes without
• Links that look like buttons in one place and plain text in another
• Form fields with different label positions or missing programmatic labels
• Custom controls that change role or keyboard interaction across pages
• Variation in error message placement or phrasing

Practical implementation steps

1. Inventory components: list every button, link, input and widget used across the product.
2. Define a single source of truth: publish a component specification that covers accessible name, role, visual style, keyboard behaviour and states.
3. Match accessible name to visible label: ensure programmatic names match what the user sees.
4. Standardise keyboard interactions: same keys and focus order for equivalent controls.
5. Use consistent ARIA when needed: use the same ARIA roles and states for the same components. Prefer native elements where possible.
6. Document exceptions: when a control must differ, describe why and how to make the difference explicit to users.
7. Automate checks: add lint rules and component tests that verify accessible-name presence and role consistency.
8. Include acceptance criteria in tickets and PRs that reference the component spec.

Small code example: inconsistent vs consistent

Inconsistent: two icon buttons that behave the same but only one has an accessible name.

<button class=“icon-btn”><svg>…</svg></button> <button class=“icon-btn” aria-label=“Save”><svg>…</svg></button>

Consistent: both have the same accessible name and role.

<button class=“icon-btn” aria-label=“Save”><svg>…</svg></button> <button class=“icon-btn” aria-label=“Save”><svg>…</svg></button>

Testing and acceptance criteria

Test manually and with tools. A good acceptance definition for a component might read:

• The control exposes a programmatic name equal to the visible label.
• The control uses the same role and keyboard interaction as other controls with the same purpose.
• Visual styling indicates state changes consistently across pages.
• Error and helper text appears in the same place and uses the same phrasing patterns.

Manual checks to run:

• Keyboard only: tab to each instance and verify focus order and action keys.
• Screen reader: listen to how the control is announced and confirm names and states are identical for equivalent controls.
• Visual review: compare two pages that use the same component to confirm styling and placement match.

Automated tools such as axe, Lighthouse or WAVE can catch missing names and some role misuse. They cannot judge phrasing or whether behaviour feels consistent, so include human tests.

Common mistakes and how to avoid them

• Relying on visual similarity only. Fix: make programmatic names match visuals.
• Using different text for the same action (“Send” vs “Submit”). Fix: pick one verb and apply it consistently.
• Mixing native and custom controls without documenting differences. Fix: prefer native elements or document the custom behaviour.
• Adding ARIA attributes inconsistently across the component library. Fix: centralise ARIA usage in the component implementation.

Design system rules and developer workflow

Make consistency part of your pipeline:

• Store component rules in the design system, not only in examples.
• Use Storybook or similar to show accessible-name and role in component stories.
• Add accessibility linting to CI to block regressions that remove programmatic labels or change roles.
• Review PRs for wording changes to link and button text as part of the QA checklist.

When differences are acceptable

Not every visual difference is a violation. Differences are fine when they convey different meaning. To keep it safe:

• Make differences explicit in the accessible name or hint.
• Document the reason for the difference in the component spec.
• Ensure keyboard behaviour remains predictable even if visuals vary.

Quick 5-minute audit

1. Open three pages that include your top 10 components.
2. Check each component for a visible label and a matching programmatic name.
3. Verify role and keyboard interaction match across pages.
4. Confirm state text and placement match (errors, hints, selected state).
5. Note any inconsistencies and file one ticket per component type with examples and acceptance criteria.

Final notes

Consistent Identification reduces surprises for users and makes your product easier to use and test. Treat it as both a design system rule and a QA requirement. That way similar components stay similar in look, behaviour and accessibility.