🇺🇸United States @kentr

The remaining failing case should be fixed by 🐛 Numeric value on exposed filter form is missing accessible name Active .

First draft in issue branch. Still needs tests.

kentr → created an issue.

It looks like the original plan was to check for non-empty #title properties, but the MR only checked with isset().

Empty text doesn't provide an accessible name, so I changed the check to fully disallow empty #title properties. This caused a lot of new errors. Some of them are from 🐛 Content: Publishing status (grouped) is missing labels for inputs Active . I think the others are from the Views exposed filter forms themselves.

I also added aria-label to the conditions.

The Remove checkboxes are also visible in Gin. Based on #3375806-14: Views 'Rearrange' dialog show the 'Remove' checkbox, which should be visually hidden → , it looks like they should be hidden with the js-hide class in another issue.

Yeah, the Remove checkboxes have display: none in the views_ui module and in Claro.

Claro then overrides that with .form-boolean. It's probably an accident because it's a generic selector. I haven't checked Gin.

I think there's a bigger issue of whether they should be visible at all, but I'm planning to give them a hidden label due to 📌 Test that all form elements have a title for accessibility Needs work (which will require a #title property).

I was wrong about the Remove checkboxes. They are still missing labels.

The strange thing is that it looks like they're not supposed to be visible. There's this comment in the code, and they don't appear when the admin theme is Stark.

// No title is given here, since this input is never displayed. It is
// only triggered by JavaScript.

It looks like the Remove checkboxes have been fixed.

I found other cases: The textfields for numerical filters. I think it's called the "in operator".

I think I have a fix, and will update the IS and create an MR. I think this is testable in Nightwatch.

It looks like the MR uses aria-label in places where there's already text.

I believe the problem is that all of the existing text is hidden with display: none (which completely hides an element, even from AT).

My suggestion is to avoid aria-label and hide the text names visually, so that they are still available to assistive tech. This avoids redundancy, and recent Slack discussions in the #accessibility channel indicate that visually-hidden text is preferred over aria-label. There's more information on that in the issue summary.

My quick experiment indicated that using core's visually-hidden CSS solves the problem.

Off the top of my head, I think it would be possible to replicate the CSS rule into a selector that applies to the text of the elements (they appear to all be wrapped in span) when the toolbar is collapsed. Maybe there's already a selector for this state. I don't remember. I also don't know what the Gin maintainers prefer regarding implementation.

I think the the proposed fix for 🐛 Elements in closed sidebar are focusable Active will also fix this.

I didn't point this issue out explicitly, but experimenting with visibility: hidden did remove the items from the VoiceOver rotor.

Question about the new validation code:

The code checks for the aria-labelledby attribute but not the aria-label attribute.

Was aria-label intentionally omitted? It's a valid method (though not preferred) of providing an accessible name, and it looks like core uses it for fields.

I'm also working on other test failures.

There are some uses of #label in the Content Translation and Language modules. Removing it (comments #197 & #202) caused several Exception: Warning: Undefined array key "#label" errors in tests.

Another error is caused by the missing #title for the test element in WeightTest.php.

I'll push an update that resolves these.

I found that some errors are due to:

• A mismatch between the expected message and the actual message used inFormBuilder::doBuildForm.
• The deprecation of @expectedDeprecation annotations.

I'm updating the MR for these.

Added 🐛 Links and buttons in toolbar missing accessible name Active to IS.

@catch:

I would also want the option to set it to a lower level if we can get tests to pass.

The current MR on 📌 Automated A11y tests in PHPUnit Active supports passing Axe options with individual tests. The options can include the WCAG versions / levels to run (as tags). The test for that can be improved to explicitly test for disabling WCAG 2.2. Would that do it?

Suggestion for remaining tasks: Configure our Nightwatch implementation to use 2.2 for all Axe tests.

Looks like STR is still needed.

Adding Novice tag so novices can find this for those todo items in the IS.

Are tests still needed, or can that todo item be marked as done?

This point about WHCM (aka, forced-colors) by @andrewmacpherson in #56 hasn't been addressed. Is that intentional?

I was chatting with @rainbreaw about another potential use for this is in Windows high-contrast mode. Instead of trying to get an asterisk to display in :after, Windows high-contrast mode could use the actual required text (i.e. don't hide it).

Added 🐛 Elements in closed sidebar are focusable Active .

kentr → created an issue.

I see where the update behavior is being cancelled: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/autocomp....

I can't determine why that code is necessary, though. Maybe for cases where the field can contain multiple items?

I tested without any focus handler at all, and the input value does change as I arrow down. Attaching a video to illustrate.

It might be worth testing that configuration in JAWS.

I'm not experienced with JAWS, so just throwing out some thoughts.

This comment on an old JQuery UI Autocomplete issue indicates that JAWS exits Forms Mode if the input is not updated.

If you do not update the input field then you will encounter a problem with JAWS where multiple down arrow keypresses simultaneously cause JAWS to pop out of forms mode and stop accepting further user arrow keys as inputs to the input element.

I noticed that in our case the input does not update when arrowing through the options, so I'm wondering if this is causing JAWS to exit Forms Mode.

This correlates with this JAWS page on Forms Mode, which describes JAWS automatically exiting with multiple Down Arrow presses. In case it's helpful to diagnose, that page describes a sound that indicates when JAWS exits Forms Mode.

For a comparison, does the problem happen in the JQuery UI Autocomplete demo?

Added ✨ Escape key closes multiple submenu levels Active .

kentr → created an issue.

Added 🐛 Submenu opened with hover does not close by Escape key when another menu item has focus Active .

Adding proposed resolution.

Minor edit to IS.

kentr → created an issue.

Added 🐛 Focus does not move to submenu when opened by enter or space key Active .

Added WCAG SC.

Fixed parent issue.

kentr → created an issue.

I think checking the name with .getAccessibleName() instead of checking the button text would be more robust.

I understand the goal to be presenting a usable name for AT. The name is currently in the button text, but it could get overridden in the future by aria-label or aria-labelledby. Checking with .getAccessibleName() should catch that.

Since @benjifisher said he'll be away, I'll make that change and let it go through review.

I'd also like to have a policy / coding standard for tests regarding the locating of elements by name, or role & name, when possible.

It's closer to how users interact with the page and would build in a check for the correctness of the name (if the name is incorrect, the element won't be found). Sweeps with Axe will find missing names but won't confirm that they are correct.

It looks like Nightwatch doesn't currently offer a clean solution, but Playwright does. So, maybe after 📌 Consider dropping Nightwatch in favor of Functional Javascript tests Active . Or, we could implement the workaround described in the Nightwatch GitHub issue as a custom Nightwatch command.

Another option is to replicate (fully or partially) the standard profile into the nightwatch_a11y_testing and continue using that profile with any changes this issue brings to the tests themselves.

If that's the chosen path, feel free to close 📌 Update the profile used in Nightwatch A11y tests Active and repurpose this one.

Actually two assertions, to show that the name stays constant with the toggling (i.e., to show that we fixed that problem also).

I'd love to have an assertion for the (accessible) name of the button because the choice was very deliberate.

After a little discussion on Slack, a few days ago, with @nod_, we agreed that the stable9 theme should not be changed. It already has its own version of toolbar.icons.theme.css.

Wanted to double-check because removing "Extend" and "Collapse" was a big part of the original issue: Was the intent to keep "Extend" and "Collapse" in the names for stable9?

Make some custom assertions about the component we're interested in. A dialog appears, has expected markup, focus moves to dialog. And finally run all the general ruleset AGAIN.

I can see also this for:

• Disclosure pattern in general.
• Menus 🌱 [PP1][PLAN] Accessibility review Postponed .

Uncertain if this is in scope or warrants a separate issue.

In 📌 Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation Needs work , the recommendation was to remove "Extend" and "Collapse" from the accessible names of menu toggle buttons.

This is also relevant to the Navigation toggle buttons. For example, the accessible name of the "Shortcuts" menu item toggles between "Extend Shortcuts" and "Collapse Shortcuts".

From 📌 Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation Needs work :

@andrewmacpherson (issue summary):

Currently these buttons conflate the name and state; the name of the button is the opposite of the current state. There's some unnecessary cognitive effort there, to figure out what the current state is. (This is the standard challenge with labeling a toggle control.)

@cwilcox808 ( #35 📌 Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation Needs work ):

Using the aria-expanded state instead of words like Extend/Collapse in the button name is definitely the right thing to do.

Clarified in STR that it's with the standard installation profile.

in "regular" mode you have a green background for the workspace that is live while all the other none live workspaces have an orange background (SC1.4.1 might apply here?).

Looks like that is mentioned in #2910673: Workspace UI usability review → .

in addition to that the yellow font color used on the live workspace implies that it would lead to a page but strictly speaking just an area on top of the current page is displayed.

I'd vote for making that element a progressively-enhanced button like in the MR for 📌 Use ARIA disclosure pattern for Toolbar buttons with trays Active .

Then the style can be something like this:

@media (forced-colors: active) {
  .toolbar-button[role="button"] {
    color: buttontext;
  }  
}

I'm uncertain if this is a Navigation issue or a Workspaces issue. It would be nice if Navigation handled it for all menu components.

I'd also really like to see this pattern be global, with a policy of progressively-enhancing all cases like this. Then it could be:

@media (forced-colors: active) {
  a[role="button"] {
    color: buttontext;
  }  
}

It looks like #8 demonstrates the Olivero menu, not the Navigation module menu. I can reproduce this on 11.x.

Needs tests for #5.

It should also be possible to test that the Close button is tab-able. It would be good to do that to mitigate against a regression.

I believe this would be SC 2.4.11 Focus Not Obscured (Minimum) (Level AA). It directly addresses user openable, persistent disclosures and uses slide-out navigation as an example.

When the additional content is opened, it takes focus and the tab ring is constrained to the new content until it is dismissed. This modality is somewhat like a dialog, in that a user cannot navigate beyond the opened content by keyboard without dismissing it first (typically by pressing Esc). However, unlike in a modal dialog, in some implementations a pointer user may be able to interact with content outside the opened section without dismissing it. Since this pattern potentially creates an inequitable experience between keyboard and pointer users, it should be used cautiously. That said, it does prevent the opened content from obscuring the keyboard focus in the main content, and thus should pass this SC. This is described and demonstrated in a short video in the Knowbility article in the reference section, under the section heading Keep keyboard focus in the slide-out navigation until it's closed.

Did a little research, and I believe I misunderstood ActiveText. Apparently it's for links that are being activated (pressed), not for the "active" link that corresponds to the current page.

@rkoller

in regard to updating the issue summary, instead of removing point 4 i wonder would it be the better choice to strike it through and leave a note

👍 Good idea.

on the other hand the active menu item for the current site is close to invisible, but that has already an issue for the none forced color mode (#3426468: Make the active menu item visually stand out more). so i wonder about two things, should the forced color mode with the active menu item be fixed in the aforementioned issue or within the scope of this issue?

I don't know. It may need more than a system-color change.

I tested ActiveText in all Edge Page Colors themes and using the emulation in Chromium DevTools. The color is indistinguishable from LinkText. Shouldn't ActiveText be a distinct color?

There was a Chromium bug related to this.

Here's a screenshot in Page Colors Dusk theme. The "Appearance" item is current and has the following CSS.

@media (forced-colors: active) {
    .toolbar-button.current {
        color: ActiveText;
    }
}

Firefox uses a distinct color for ActiveText.

maybe point 6 should be rescoped to the not visible bottom border in desktop view port and point 8 should be solely about the hamburger. that way the two images used are more appropriate? if you agree i can update both points in a follow up comment.

👍 Sounds good.

Adding a new issue: More actions button should have a border (related Slack discussion).

This may be fixed by 📌 Improve visibility of More actions menu button Active , but does the menu "Close" icon also need a border?

Add Usability tag to emphasize that I believe this also affects regular users. AFAIK, I have "normal" (though imperfect) vision.

Added 📌 Improve visibility of More actions menu button Active as a child issue. It's different from 🐛 The icon for the more actions button is not visible Active .

I was uncertain whether I should change the IS here.

kentr → created an issue.

Regarding tests, I suggest looking into calling the Nightwatch admin a11y tests with the --adminTheme option.

Based on the README, this might be the command:

yarn test:nightwatch --tag a11y:admin --adminTheme gin

Just a heads-up that in #3093378-35: Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation → @cwilcox808 cautioned against using aria-label instead of hidden text for buttons due to lack of support in translation software.

I inquired about similar concerns with other html elements for this issue in Slack.

I retract my previous comment about the interrupted menu right border. I now see it in Edge with Page Colors.

Suggestion for the remaining hard-to-see inline SVG icons:

• For the color issue, use currentColor in some form.
• For the chevrons, give them a stroke with a larger width.

Here's POC CSS:

@media (forced-colors: active) {
    svg[class*="toolbar"] path[stroke] {
        stroke: currentColor
    }
    
    svg[class*="toolbar"] path[fill] {
        fill: currentColor
    }

    :is(
        .toolbar-button__chevron, 
        .admin-toolbar__expand-button-chevron
    ) path {
        stroke-width: 5%;
        stroke: currentColor;
    }
}

Screenshot:

For IS #9 (gap in menu right border) I'm only seeing the issue in Firefox (Mac).

Also noticed another issue: The icon next to the username at top is hard to see. It may not be a UX / accessibility problem, though.

Screenshot attached from Chromium.

Tweaking the STR a little more.

I believe #4 in the IS (regarding the outline of the hovered menu entry) is caused by automatic dark mode. I can't reproduce it in basic forced colors emulation or MacOS Edge with Page Colors.

I suggest removing that item. @rkoller, does this sound right, and do you agree that item can be removed?

Is #6 in the IS referring to the hamburger icon that #8 refers to?

I'm also adding Page Colors to the IS for seeing forced-colors mode. It's a little nicer DX than forced-colors emulation in DevTools.

Would this be SC 2.1.1?

kentr → created an issue.

Adding a suggestion:

📌 Use ARIA disclosure pattern for Toolbar buttons with trays Active will hopefully result in the role="button" added by JavaScript instead of it being present in the initial markup.

If that issue lands before this is completed, it would be great to include here some CSS rule(s) based on role="button" that will set the system-color of toolbar buttons to ButtonText after they are processed by JavaScript.

Something along these lines:

@media (forced-colors: active) {
  .toolbar .toolbar-item[role="button"] {
    color: buttontext;
  }
  .toolbar .toolbar-item[role="button"]::before {
    /* Assuming background images are converted to mask images. */
    background-color: buttontext;
  }
}

There's related discussion here.

I do not recommend letting 📌 Use ARIA disclosure pattern for Toolbar buttons with trays Active block this issue, though.

Hero text has insufficient contrast

Both the Axe extension and Accessibility Insights are reporting insufficient contrast for the normal text in the hero. Confirmed with the WebAIM contrast checker.

Attached screenshot of Accessibility Insights report and report html export.

To reproduce

Run a test on the home page with Accessibility Insights or the Axe extension.

Attaching screenshots of results from layout builder block search, vanilla 11.x and then with the MR @ c199cc2d.

For the IS descriptions, I'm not clear on what's needed regarding HTML structure and don't want to get the grouping information wrong. Hopefully someone else can glean that from the screenshots.

I'm not an accessibility expert either.

I think the underlying problem with the button text is that there's also text indicating what the button will do (the "action" component) and that it is the opposite of the "state" of the submenu and what's indicated by the icon. From the IS:

the [accessible] name of the button is the opposite of the current state. There's some unnecessary cognitive effort there, to figure out what the current state is.

When the submenu is collapsed, the icon shows that but the text in the button text says "Extend [sub-menu]".

Using aria-labelledby to avoid repeating "[sub-menu]" in the button text would be convenient if it worked, but maybe it's not feasible.

Sorry, disregard the image attachment in my last comment. It was an accidental holdover from an earlier version of the comment.

RE #30, I suggest:

1. Don't use aria-labelledby.
2. Revert to having the label component in the button text.
3. Keep the action component out of the button text to resolve the problem described in the IS.
4. Add an assertion in the test to confirm that the button accessible name equals the text of the corresponding link (the link that was used for aria-labelledby).

I think that will also resolve @nod_'s comment in the MR.

I've made some suggestions on the MR for these.

Rationale

I'm guessing that aria-labelledby was a result of @Max Starkenburg's comment in Slack:

After further reflection (and defaulting to trusting Andrew's judgement on something like this), I'm realizing that it probably indeed made sense to try to remove a description of the state from the button, since I believe most screen readers will already announce the change in the aria-expanded value anyway (e.g. VoiceOver seems to announce "[accessible name], collapsed, button" when tabbing to such a button).

That led me to wonder what the accessible name should be. I sought out "what would Adrian Roselli do for such disclosure widgets?" leading to https://adrianroselli.com/2019/06/link-disclosure-widget-navigation.html#Name, in short, to use the name of the sibling link (via aria-labelledby). I think Andrew's patch was to use "[sibling link text] sub-menu", and looks like WAI's example uses "more [sibling link text]". I think neither of those quite contribute to the same type of verbosity problem Adrian reneged on (which seems to have been to toggle "show [sibling link text]" and "hide [sibling link text]").

Added STR

I incorrectly assumed that when not in Claro, the toolbar styles are provided by the Toolbar module.

It turns out that Claro overrides the toolbar styles even when it's not the default theme: #3070493: Introduce a mechanism to provide an alternate Claro design for the toolbar in the future → .

If Claro is the admin theme and Olivero (or a random other theme) is the default theme, Claro will dictate the toolbar styles for the default theme also.

So, it looks like we do have to change both the Toolbar module and Claro for this issue.

Actually, needs better STR.

Based on @cwilcox808's comments 📌 Use ARIA disclosure pattern for Toolbar buttons with trays Active and another related Slack discussion, I'm moving aria-controls to a separate issue.

I'm moving the suggestion for forced-colors proper button coloring to another issue because it's pretty involved after all.

Fixed links in previous comment.

There are reports of severe usability issues in Gin related to filtering on the modules and user permission pages. So it might make sense to bump up the priority of this.

• https://drupal.slack.com/archives/C1BB308HH/p1753277604476329?thread_ts=...
• https://drupal.slack.com/archives/C1BB308HH/p1753260051759719

kentr → created an issue.

Forgot to add SC 4.1.2.

Also adding Needs change record because of the UI / UX changes.

Removed Global2020 because it's outdated.

Added SC 4.1.2 because this issue is related to the role and state of UI components and the notification of changes to assistive technologies.

Added progressive enhancement for all "faux button" properties to the Proposed resolution and changed to Bug report because it's a failure of SC 4.1.2 when javascript is disabled.

Added forced-colors CSS to Proposed resolution because it's probably just a color change, but left out the suggestion of changing the full-color styling to present as buttons because that's a bigger design change and should apply to all buttons in the toolbar. #3097905: Add visual indicator to show which toolbar buttons have trays associated with them → is probably a good place to address that because it already requires related design.

I updated the proposed resolution and added a todo item for the CSS. I believe this addresses the issue summary updates requested in #28.

I don't have time to do a full review, so I'm not striking out any of the todo items.

Adding Needs change record because the policy requires it for changes that affect UI / UX → .

The MR pipeline failed. It looks like it's from the JS size change and the value for ScriptBytes in AssetAggregationAcrossPagesTest.php needs updating. Removing the CSS may also require a change there.

I rebased the MR and made a couple of minor changes on the CR draft.

The conflict was due to the deprecation of template_preprocess_form() in 📌 Convert template_preprocess in form.inc Active , so please check that I put the novalidate change into the correct new place.

I've converted the action back to two event handlers.

I moved the tests to Nightwatch in order to use the sendKeys() function. AFAICT, this simulates actual typing on the element instead of firing raw keyboard events, and makes the ENTER key fire a click event on the element as it should. I didn't see a way to do that in FunctionalJavascript tests.

Adding Needs change record because the policy requires it for changes that affect UI / UX → .

If it's in scope, I think this related test is passing falsely and needs fixing.

I've observed that the condition that appears to symbolize the appearance of the submenu after clicking will be true even when there's no click.

I checked this in the browser when the submenu is collapsed, and in the test by commenting out the click on the submenu.

I believe it needs a check before the click to confirm that the item is not visible, and then a check after the click to confirm that it has become visible. It looks like the checkVisibility() function might work for this.

It might also be checking the wrong submenu. When testing in the browser with that test code and the nightwatch_testing installation profile, I observe that the click is on the Configuration menu rather than the Reports menu. #toolbar-link-user-admin_index is one of the items that become visible.

The missing h1 appears to be due to the bug that NodeTitleTest.php was created for ( 🐛 Display the page title, even if "0" in olivero Fixed ). When I give a node a title other than "0", the title and h1 are present. Screenshot:

The title "0" is present in the browser and the test passes when I add a template override to Gin and apply the changes that were made for Olivero:

LMK if you want me to push the template change to the MR. The original template comes from Classy; I got the source from twig debug mode.

Sorry, didn't see #5.

There are pipeline failures.

I just learned that Gin inherits a lot of Claro code: 🌱 [META] Gin 6.x Active .

So, limiting this change to the Toolbar module may not solve the problem in Gin (if it exists at all). But I'm guessing that any change to Claro libraries for 🌱 [META] Gin 6.x Active is best done specifically as part of that effort so that it can be analyzed beforehand.

@libbna,

My thinking is that fixing the icons in the Toolbar module will still resolve the issue in any theme that doesn't override them.

Olivero doesn't AFAIK, so the changes will take effect on non-admin pages by default. And for Drupal CMS admin pages, the change will also appear there if Gin doesn't override the icons.

If there's a need to resolve the problem for Claro, it can be a separate issue that's specific to Claro.

@libbna

In comment #6, @kentr suggested removing the Claro overrides. However, I had a follow-up question: if we remove those overrides, do we have alternative images or icons to use in their place? If not, what would we be replacing them with?

Now that Gin will replace Claro → , I'd say disregard my suggestion in #6.

But just to clarify the thought behind it: I was suggesting removing the Claro overrides for these particular icons altogether so that the icons won't go back to being broken when the admin theme is Claro (i.e., with the Standard installation profile).

Some of the icons also need attention for the "pressed" and / or "active link" states. Here's a screenshot.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

@benjfisher

...@rkoller suggested using aria-pressed instead of aria-expanded...
Does that apply here? Should we consider it?

The place in the video that @rkoller linked is regarding a button that toggles light / dark mode. aria-expanded wouldn't apply to that, I believe, because in that use-case there's nothing to expand or show.

Later in the video, there's an example of a show / hide toggle button with aria-expanded. The video creator appears to approve of that use.

There's a separate question of whether to change the "label" (visual display) when the toggle is activated. I can't speak to that. I find changing icons for show / hide widgets (like the orientation of a caret) to be helpful.

When Javascript is disabled and those items behave as links, they still have role="button" and (currently) aria-pressed="false".

In this case, they may be wrongly announced to AT as buttons instead of as links. Attached a screencast of this in VoiceOver.

Based on a Slack discussion with @cwilcox808, I suggest:

1. Rendering these items as plain links without any HTML button properties (aria-role, aria-expanded, aria-controls, etc).
2. Adding those button properties in Javascript as part of the progressive-enhancement.
3. Adding CSS based on aria-role="button" that will style these as buttons instead of links when the progressive-enhancement has happened (both for full-color and forced-colors cases).

@cwilcox808 said this about the full-color styling and aria-controls:

I think that's a good idea independent of the forced-colors state, something like:

.toolbar a[role="button"] {
  text-decoration: none;
}

Instead of .toolbar .toolbar-item including text-decoration: none.

That does open up the use of adding the underline on :hover and :focus. I really like strongly associating underlines with links (behaving as links) so I'd like to see something else used when they have [role="button"]. Without JS, the line thickness could be changed, e.g.

.toolbar a[href]:not([role="button"]):is(:focus, :hover) {
  text-decoration-thickness: 0.1875em;
}

Note that only a single assistive technology, JAWS, makes use of aria-controls so it's not very useful. The better practice is to instead have the associated element immediately follow the control so users don't have to navigate through other content from the control.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

I misunderstood the reason for using keyup with the space key.

I'll change it back to using two events and clarify that in the IS.

Back to needs review.

Also discovered that SPACE and ENTER keys do work in Safari when tab navigation is enabled the settings.

Just added tests involving the ENTER key, as specified by the proposed resolution.

NW until pipeline passes.

Made attempt to fix the patch apply error in #36. The current MR diff applies cleanly to 11.x for me.

There was one pipeline error that appeared to be related to the recent infrastructure problems and passed when re-run.