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.
Comments
Comment #2
kentr commentedComment #3
kentr commentedComment #4
kentr commentedComment #5
kentr commentedComment #6
kentr commentedComment #7
mherchelNote 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.
Comment #8
mherchelThe issue above is now merged. @kentr, can you re-test and make sure the issue no longer exists?
Comment #9
kentr commentedCould 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-hiddeninto 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-hiddenadded to them.