#Accessibility

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

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

Okay so think this doesn't need an issue summary actually.

Tabbing through the hover is now activated

LGTM

Added a draft change record.

Just tested with Gin, it doesn't seem to be affected due to not using Claro's page.html.twig

camilledavis → closed merge request !3876

New version of the patch attached. This version corrects an issue where the behavior triggered twice when the spacebar was pressed, but only once when the enter or mouse buttons were pressed.

This has been rebased of the last commit on 11.x. Setting back to "Needs Review."

Voiceover announces the row (see screenshot), so I removed the reference to screen readers from the description.

Change record looks good so removing that tag.

Added release note to the summary

But MR appears to need a manual rebase.

Went to review but appears MR has some failures

For the short term, simply adding an ID to the checkbox label does the job; the use case is Simplenews subscriptions on user register page.

/**
 * Implements template_preprocess_form_element_label().
 */
function my_custom_theme_preprocess_form_element_label(&$variables) {
  $id = $variables['element']['#id'] ?? '';
  if ($id && str_contains($id, 'edit-subscriptions-')) {
    $variables['attributes']['id'] = 'edit-subscriptions--description';
  }
}

re-roll patch according to the latest code changes.

I will have look, thanks

Just running into this issue in a custom theme. Here is the code sample that generates the «Broken ARIA reference» error:

<!-- BEGIN OUTPUT from 'core/modules/system/templates/input.html.twig' -->
<input data-drupal-selector="edit-subscriptions-sip-n-savour" aria-describedby="edit-subscriptions--description" type="checkbox" id="edit-subscriptions-sip-n-savour" name="subscriptions[sip_n_savour]" value="sip_n_savour" class="form-checkbox">
<!-- END OUTPUT from 'core/modules/system/templates/input.html.twig' -->

<!-- BEGIN OUTPUT from 'core/modules/system/templates/form-element-label.html.twig' -->
<label for="edit-subscriptions-sip-n-savour" class="option">SIP n’ SAVOUR</label>

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to hidden.

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to active.

I like the idea of removing the config option extlink_target_append_new_window_label which defines the label text and is new to this patch, always using the recommended text, and linking to the external resource (from above). This isn't removing an option in production. This is removing an option that someone in this thread thought helpful, and replacing it with a standardized (maybe industry standard) a11y text.

The current patch checks for "new window" in the existing label (not "opens in a new window") so I think that the existing patch is already backwards compatible with production systems.

If we agree, then what's left is to remove the config option extlink_target_append_new_window_label and make sure the tests work. If I understand correctly, we're pretty much at the place that you started with this ticket, it just took me a while to get there (sorry). What do you think?

@pdureau Although I think I understand your statement, I believe this issue requires a lighter modification than expected ^^?

Thanks, I have tested and it's working fine.

I've succesfully applied MR46. First a feedback about the points listed in the issue summary:

* When expanded, it should be possible to click outside of the button to close the dropdown.

that works as described but i wonder if would it make sense to close the dropdown also when the user clicks inside the preview area? at the moment it only closes when the dark title bar, the frame in slightly lighter dark or one of the other buttons is clicked.
and talking about closing the dropdown the usual pattern keyboard users are familiar with is pressing the ESC key. but that immediately closes the entire preview window. would it be possible and make sense when ESC key pressed and the dropdown is open the dropdown is closed while if the dropdown is closed and the ESC key is pressed the preview window is closed?
And there is also no aural feedback when the dropdown is showing or closed - a screenreader user is unaware if a dropdown is opened or closed (see keyboard_vo.mp4). that might be accomplished by introducing a toggle or switch button for the settings button?

* It should be possible to click on the checkbox to toggle an option in addition to clicking on the link.

That works as described in the issue summary the only problem i notice is if you navigate by the keyboard and you have the screenreader announcement active. that way you get two announcements per setting within the aural interface (see keyboard_vo.mp4) which is sort of redundant.

✅ The dropdown should not overlap other buttons.

✅ Dropdown links should show pointer on hover.

✅ Preview panel jumps slightly when view mode control is added or removed.

aside those points there are two more details to note. First the focus outline has a too low color contrast with 1.5:1 it should be at least 3:1.

and one detail about settings in general. those four settings overlap with the settings found on /admin/config/content/same-page-preview in one setting, the "open preview by default". but that surfaces one problem. it is not clear to me at all if the settings on the node are "individual" settings aka overrides on a per node basis or a mirror of the global overall settings (on a sidenote "open preview by default" is way more clear than "on by default" on the settings page)? i've unticked the "on by default" checkbox on /admin/config/content/same-page-preview while "open preview by default" is ticked on the node preview, when i open a node the preview window is opened automatically though. that is confusing, me as the user i always ask myself which of the two counts and is there a "hierarchy" or do the settings simply mirror themselve? having that kind of settings in two different places, with some only available on the node others only availble on the config page and some availble in both places, is simply confusing.

Move changes from #71 to merge request

Re-roll of patch of #18 for 10.2.6 attached.

This proposed solution reduces the search box maxlength to 80 characters on desktop and 45 characters on screens smaller than 768px.

I added the suggested aria-pressed attribute to the Link and Grid buttons that functions similarly to the two button grouping on https://tink.uk.

However, I wasn't sure how to go about applying the hover and active state styling on them given that the background color of the selected display button (either Link or Grid) in any state is the same as the design system's button active state background color. (In other words, the background of a selected Link or Grid display button is always #ADAEB3). When hovering over a selected display button, should it get 15% darker than #ADAEB3, and 30% darker if the user clicks it again? I looked around in the design system and other admin pages to try to find an example to copy, but couldn't.

I was thinking a solution to this hover/active state styling problem could be changing the color of the selected display button to blue, and then apply the design system's hover and active state styling as usual. Project Browser's Figma Designs shows an example of this on the "Updated MVP April 2022" page, on the frames that start with "April 2022: New Design Draft", but since they're called drafts, I wasn't sure.