Problem/Motivation

First draft, to be fleshed out...

Labels for accent color choices on the theme settings form are totally hidden with display: none.

This occurs both:

  • On the admin page settings form.
  • On the user settings form when the "Users can override Default Admin settings" option is enabled (therefore, regular users can encounter this).

WCAG success criterion

SC 4.1.2 Name, Role, Value (Level A)

Deque impact rating: Critical

Accessibility Insights report

This is from the user settings form case, and for only one of the color options. There are twelve errors total.

Title: WCAG 4.1.2: Ensure every form element has a label (#edit-preset-accent-color-blue)
Tags: Accessibility, WCAG 4.1.2, label

Issue: Ensure every form element has a label (label - https://accessibilityinsights.io/info-examples/web/label)

Target application: admin | Drush Site-Install - https://drupal-core-dev.ddev.site/user/1/edit

Element path: #edit-preset-accent-color-blue

Snippet: <input data-drupal-selector="edit-preset-accent-color-blue" data-gin-accent="blue" style="--accent-base: #015efe;" type="radio" id="edit-preset-accent-color-blue" name="preset_accent_color" value="blue" checked="checked" class="form-radio form-boolean form-boolean--type-radio">

How to fix: 
Fix all of the following:
  Form element has explicit <label> that is hidden

====

This accessibility issue was found using Accessibility Insights for Web 2.46.0 (axe-core 4.10.2), a tool that helps find and fix accessibility issues. Get more information & download this tool at http://aka.ms/AccessibilityInsights.

Steps to reproduce

  • Install Drupal with the Standard profile.
  • Log in as admin.
  • Install the Default Admin theme and set it as the administration theme.
  • Go to /admin/appearance/settings/default_admin.
  • Run a test with the Axe-core or Accessibility Insights extensions.

Proposed resolution

The labels are currently hidden by the theme's custom CSS.

I propose removing this CSS from the theme and hiding them instead with the visually-hidden class.

Hiding them visually can probably accomplished by adding '#title_display' => 'invisible' for the field(s) in the form definition (Settings::getSettingsForm()).

Because this requires CSS changes, I'm postponing based on #3582351: [Meta] Clean up CSS within Admin theme.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

kentr created an issue. See original summary.

kentr’s picture

Issue summary: View changes
kentr’s picture

kentr’s picture

Issue summary: View changes
kentr’s picture

Title: [PP-1] Labels for accent color choices on settings form are hidden » [PP-1] Labels for accent color choices on settings form are hidden from accessible technology
kentr’s picture

Issue summary: View changes
mherchel’s picture

Note that I noticed this and fixed it as part of #3599680: Consolidate, merge, and refactor Gin's CSS variable's into Admin theme's original variables.. This isn't merged just yet but should get in shortly.

mherchel’s picture

Status: Postponed » Needs review

The issue above is now merged. @kentr, can you re-test and make sure the issue no longer exists?

kentr’s picture

Status: Needs review » Fixed

Could not reproduce on main, so appears to be fixed!

I checked the theme settings form and the user settings form. Accessibility Insights does not report this error anymore.

I still think we should look at integrating core's .visually-hidden into these labels as a followup. Esp. because it looks like this case is missing some important properties that #3591112: Update the visually-hidden class proposes to add. A quick test shows that the behavior that displays the labels on hover (:active) appears to still work with .visually-hidden added to them.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.