WCAG 4.1.2 — Name, Role, Value — Custom Widget Missing ARIA Roles

Who Is Affected

People who are blind or have severe vision impairments who use screen readers, voice control software users, and people with motor disabilities who use keyboard-only navigation or switch devices.

What This Means

When developers create custom interactive elements beyond standard HTML buttons and form fields, they must explicitly tell assistive technology what these elements are and how they work. This is done through ARIA (Accessible Rich Internet Applications) markup that provides three essential pieces of information:

• Name: What the element is called
• Role: What type of element it is (button, slider, menu, etc.)
• Value: Its current state (expanded/collapsed, selected/unselected, current value)

Common failures include custom dropdowns that screen readers see as generic <div> elements, image carousels with no navigation labels, or toggle buttons that don't announce their current state.

Fix: CMS / Theme

Most custom widget issues stem from theme components or third-party plugins that weren't built with accessibility in mind.

Identify Problem Widgets

1. Use the axe DevTools browser extension to scan your site
2. Look for violations mentioning "Elements must have sufficient color contrast," "ARIA," or "roles"
3. Common culprits: custom dropdowns, image sliders, tabs, accordions, modal dialogs

For Joomla Sites

1. Check your template's custom modules:

   • Go to Extensions → Modules
   • Edit any custom modules that create interactive elements
   • In the module's PHP or HTML output, add appropriate ARIA markup

2. For third-party extensions:

   • Update to the latest version first (accessibility often improves in newer releases)
   • Contact the extension developer if ARIA support is missing
   • Consider switching to an accessible alternative

For WordPress Sites

1. Theme customizer widgets:

   • Go to Appearance → Customize → Widgets
   • Remove or replace any custom widgets that create inaccessible interactive elements

2. Plugin conflicts:

   • Check recently installed plugins, especially sliders, contact forms, or menu plugins
   • Deactivate and test to isolate the problematic plugin
   • Replace with accessible alternatives from the WordPress repository

Common ARIA Fixes

Add these attributes to your custom widgets:

• role="button" for clickable elements that aren't <button> tags
• aria-label="descriptive name" for elements without visible text
• aria-expanded="true/false" for collapsible content
• aria-selected="true/false" for selectable items
• aria-current="page" for current navigation items

Fix: Content Editor

If the problematic widget was added through a page builder or content editor:

1. Identify the widget: Look for elements that visitors can click, tap, or interact with
2. Check for alternatives: Can you accomplish the same goal with standard HTML elements?
3. Replace if possible: Use native form controls, standard links, or built-in CMS components instead
4. If custom elements are required: Work with your IT department to add proper ARIA markup

Standard Reference

WCAG 2.1 Success Criterion 4.1.2 — Name, Role, Value, Level A

For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

• W3C Understanding SC 4.1.2
• WCAG Technique ARIA4 — Using a WAI-ARIA role
• WCAG Technique ARIA16 — Using aria-labelledby
• WCAG Failure F15 — Change of context without user request
• WCAG Failure F20 — Opening new window without warning
• WCAG Failure F68 — User interface control without name
• WCAG Failure F79 — Focus not visible