Assess Drupal core for WCAG success criterion 2.5.3 Label in Name

That looks like it is 25-27.01.2019 - that right?

Would this be a big Google Spreadsheet we'd be building on? Not sure how to do this type of system wide review.

I think this is more of a search for issues, rather than "there are issues"

The best is as discussed earlier, split the module or theme sub issue, will help to fix the issue.

With a lot of help from AI, I've made some progress on this.

Goal

Assess and fix Drupal core components for WCAG 2.5.3 Label in Name compliance. This criterion ensures that the accessible name of a control contains — and best practice is to start with — the visible text label that users see on screen.

This matters for speech recognition users who say "Click [visible text]" to activate controls. If the accessible name doesn't match the visible text, the speech software cannot find the control, forcing the user to resort to slower workarounds like numbered overlays or spatial grids.

This issue tracks the assessment. Child issues will contain the fixes, one per component.

How Speech Recognition Identifies Controls

Speech recognition software (Dragon, Apple Voice Control, Windows Speech Recognition) matches spoken commands against the accessible name of each control on the page. The primary interaction is:

User says: "Click Save"

Software searches for a control whose accessible name contains "Save"

Match found → control activated

When multiple controls share the same accessible name, the software highlights all matches with numbers. The user must then speak the correct number to select the one they want. This adds a step to every interaction.

When no match is found, the user must use spatial methods — MouseGrid (Dragon), Show Numbers (Apple Voice Control) — displays numeric labels next to every visible interactive control, like "Show names" but shorter.

"Show grid" is the Apple command which overlay the page with numbered grids and require drilling down to the target. This is significantly slower and more tedious.

Three Categories of Violations Found

Category 1: [Advisory] Visually-hidden text appears before the visible label

The accessible name starts with text the user cannot see. When the user says "Click [visible text]", the software cannot may not be able to match because the accessible name begins with different text.

Example:

<!-- User sees: "Image" -->
<!-- Accessible name: "Show Image media" -->
<span class="visually-hidden">Show </span>Image<span class="visually-hidden"> media</span>

The user says "Click Image" but the accessible name starts with "Show". The software may not find a match or may respond better if the user says the full "Show Image media".

Why this is a problem: Where possible, have the visible text at the beginning of the accessible name. Speech users will likely use the text they see rather than the words they cannot see.

To meet WCAG 2.5.3 the visible words must generally be:

• present in full;
• in the same order;
• contiguous, without hidden words inserted between them.

Locations found:

• Media Library tab buttons (Show @title media)
• Navigation admin menu (Extend before menu item title)
• Locale translation form (Source string / Translated string before visible content)
• Content translation table headers (bundle name before field/column label)
• Locale translation update info (Show description before visible text)
• Status report counter (severity text before "Details")

Perhaps first ask whether Show and media belong in the name at all. A tab named Image already exposes its tab role and selected state. The tab semantics communicate that activation displays its associated panel. WAI-ARIA tabs pattern.

Category 2: aria-label diverges from the visible text

The element has an aria-label that contains different text than what is visible. The accessible name (from aria-label) does not contain the visible label text at all, or starts with different text.

Example:

<!-- User sees: "Menu" -->
<!-- Accessible name: "Main Menu" -->
<button aria-label="Main Menu">Menu</button>

The user says "Click Menu" but the accessible name is "Main Menu". Some speech engines (notably iOS Voice Control) may require the accessible name to start with the visible text. "Main Menu" does start with "Menu" — but consider the reverse:

<!-- User sees: "(Experimental)" -->
<!-- Accessible name: "View information on the Experimental status of the module Node" -->
<a href="..." aria-label="View information on the Experimental status of the module Node">(Experimental)</a>

The user says "Click Experimental" but the accessible name starts with "View information on". The visible text "(Experimental)" is not at the start of the accessible name.

Why this is a problem: The aria-label completely replaces the visible text as the accessible name. If the aria-label doesn't start with or contain the visible text, speech users cannot activate the control by speaking what they see.

Locations found:

• Olivero mobile nav button (aria-label="Main Menu" vs visible "Menu")
• Field re-use button (aria-label="Reuse @field" vs visible "Re-use")
• Module lifecycle links (aria-label="View information on..." vs visible "(Experimental)")
• Non-stable module confirm form (aria-label=" about the status of..." vs visible text)
• System modules details summary (aria-label="Details for @module" vs visible description)

Patterns to watch out for:

• Save versus Confirm changes: WCAG failure.
• Re-use versus Reuse: avoid the discrepancy, but do not declare it a confirmed failure without applying the relevant language and punctuation rules.

The best default remains avoiding aria-label when visible content already produces a correct name. This keeps the visible label, accessible name, and translation source synchronized.

Category 3: Repeated identical text without disambiguation

The same visible text (e.g., "Edit", "Delete") appears in every row of a table or list with no aria-label or visually-hidden text to distinguish them.

Example:

<!-- Row 1 -->
<a href="/edit/state/1">Edit</a>  <a href="/delete/state/1">Delete</a>
<!-- Row 2 -->
<a href="/edit/state/2">Edit</a>  <a href="/delete/state/2">Delete</a>
<!-- Row 3 -->
<a href="/edit/state/3">Edit</a>  <a href="/delete/state/3">Delete</a>

The user says "Click Edit". The software finds three matches and highlights them with numbers: 1, 2, 3. The user must then say "Choose 2" to select the second one. Every. Single. Time.

Compare with the correct pattern (already used in core's EntityListBuilder base class):

<a href="/edit/format/basic_html" aria-label="Configure Basic HTML">Configure</a>
<a href="/edit/format/restricted_html" aria-label="Configure Restricted HTML">Configure</a>

The user can say "Click Configure Basic HTML" to directly activate the correct link without numbered disambiguation.

Why this is a problem: Every additional disambiguation step adds cognitive load and slows down the interaction. In a table with 20 rows, a speech user must speak two commands (number + confirm) for every action instead of one.

Locations found:

• Workflow edit form: "Edit" and "Delete" repeated per state and transition
• Comment admin: "Edit" repeated per comment
• Shortcut set customize: "Edit" and "Delete" repeated per shortcut
• Image style edit form: "Edit" and "Delete" repeated per effect
• Config translation: "Edit", "Delete", "Add" repeated per language
• Block list builder: visible text changed to "Configure"/"Remove" but aria-label still says "Edit"
• Field config list builder: "Edit" and "Delete" with no aria-label at all
• Node revisions: "Delete" repeated per revision
• Content translation: "Delete" repeated per language
• Workspace list: "Manage" repeated per workspace

Unique accessible names can help:

• screen-reader users navigating a list of controls;
• Dragon and Windows Voice Access users who know or can infer the additional words;
• other users when the contextual name is exposed through an overlay.

But the feedback is correct: hidden specificity does not guarantee less work for a speech user who does not know that hidden name. Apple users may still need “Show names” or “Show numbers.”

Link text does not automatically fail WCAG 2.4.4. Link purpose can come from programmatically determined context such as the enclosing table cell, row headers, list item, or paragraph.

Proposed Child Issues

Each slice targets one component, with a minimal fix and one focused regression test.

Additional child issues can be created for:

• Locale translation form (Cat 1, slices for source/plural textareas)
• Content translation theme hooks (Cat 1, bundle/field labels)
• Block list builder (Cat 3, parent aria-label mismatch)
• Field config list builder (Cat 3, no aria-label at all)
• Node revisions (Cat 3, Delete per revision)
• Remaining list builders with inherited mismatched aria-labels

References

• WCAG 2.5.3 Label in Name — W3C normative criterion
• Understanding SC 2.5.3 — intent, techniques, failures
• Testing with speech recognition — TPGi practical guide
• Browsing with speech recognition — TetraLogical walkthrough
• Speech Recognition Accessibility Best Practices — project-level guidance document
• ACT Rules Guidance

Documentation from vendors:

• Apple Voice Control (Mac)
• Apple Voice Control (iOS)
• Microsoft Voice access
• Android Voice Access