Problem/Motivation

Drupal core makes widespread use of invisible labels, aimed at screen reader users. Unfortunately these techniques can cause problems for speech control users, if used incorrectly. WCAG 2.1 introduces new success criterion 2.5.3: Label in Name to address these problems.

This issue is about auditing Drupal core for "Label in Name", and correcting any problems found.

Background reading:

Proposed resolution

  • Survey ALL instances of .visually-hidden, aria-label, aria-labelledby.
  • This is potentially a BIG survey, so we may split this plan up by module, theme, etc.
  • For any problems found, file a child issue to correct them.

Example:

  • PASS: t("Manage fields <span class="visually-hidden">for @bundle</span>", ["@bundle" => $entity->bundle()]). A speech control user can activate this by saying "Click manage fields" and their assistive tech can narrow the choices down to the instances which match. So users can choose from a handful of relevant matches.
  • FAIL: t("Manage <span class="visually-hidden">@bundle</span> fields", ["@bundle" => $entity->bundle()]). A speech control user cannot activate this by saying the visible link text. "Click manage fields" won't work, because that exact phrase doesn't appear in the names given to assistive tech. The user will have to say "Show numbers" to highlight all controls on the page, instead of just a few relevant matches.

TODO: Make a set of instructions for testing this. Flesh out the pass/fail examples to include scenarios with aria-label and aria-labelledby. A good starting point would be this answer the situations described in this Stack Overflow answer: Make screenreader say button alt-attribute instead of innerText

Remaining tasks

User interface changes

Update strings where any violations occur.

API changes

None.

Data model changes

None.

Comments

andrewmacpherson created an issue. See original summary.

andrewmacpherson’s picture

andrewmacpherson commented

I wonder if we can crowd-share this work, say as an activity in the Global Sprint Weekend.

mgifford’s picture

mgifford
he/him
Primary language English
commented

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.

andrewmacpherson’s picture

andrewmacpherson commented
Issue summary: View changes

There's a multilingual UI translation aspect of this. A review of all core code will only confirm that the default English UI strings satisfy WCAG Label in Name.

However UI translators could cause a WCAG failure here. Most of our dynamic translatable strings work by putting variables inside. I understand this is so translators have flexibility over things like word order, idiom, choosing which parts of a sentence should be linked, and the freedom to choose appropriate visually-hidden text. But when translating a string which contains a visually-hidden span, a translator could cause a "Label in name" problem if they put visually-hidden text between two visible words.

Example:

  • PASS: t("Manage fields <span class="visually-hidden">for @bundle</span>", ["@bundle" => $entity->bundle()])
  • FAIL: t("Manage <span class="visually-hidden">@bundle</span> fields", ["@bundle" => $entity->bundle()])

How can we address this?

  • Add guidance in d.o handbook pages about Label in name, with pass/fail examples, including how it might be broken by translation.
  • Encourage localization contributors to review their translations for WCAG Label in Name. How to promote this?

Added a pass/fail example to the issue summary.

andrewmacpherson’s picture

andrewmacpherson commented
Issue tags: +multilingual

I'll let the interface translation maintainer (Gabor) know about this.

andrewmacpherson’s picture

andrewmacpherson commented

#3 - @mgifford - Epic spreadsheet FTW! I don't relish the idea, but I can't suggest anything better :-)

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

andrewmacpherson commented
Issue summary: View changes

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue tags: +wcag253

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

prabuela’s picture

prabuela commented
Assigned: Unassigned » prabuela
prabuela’s picture

prabuela commented

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

prabuela’s picture

prabuela commented
Assigned: prabuela » Unassigned

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.