Dropbutton widget not accessible to screen readers

camille.davis@civicactions.com → made their first commit to this issue’s fork.

Working on MR, I think it will be necessary to put the secondary actions in their own

element so it can be marked as aria-expanded.

Noticed an additional inconsistency (at least in 9.5): hovering over the dropdown toggle button doesn't open it (you need to click), but hovering out closes it automatically. I think it should be the same action to open and close, and my preference would be clicking (so the open state does not depend on where you cursor is). So if a user with a hand tremor or other mobility impairment opens the menu and accidentally moves the cursor away, they can still access it.

Additional accessibility issue: it should be possible to dismiss the dropdown by pressing "Esc" ( reference - https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html )

This MR:

• Puts the secondary actions in a sublist
• Adds aria-expanded and aria-controls attributes to the toggle button
• Changes the toggle button text to "Show additional actions" or "Hide additional actions"

Could we add some before/after screenshots to the issue summary since the css is changing. To make sure nothing broke.

Tagging for accessibility. I currently only have ANDI installed but could use the voice over if no one gets to it.

Left some feedback on the MR.

This is an issue with dropbuttons in general, not specific to Claro, the title and issue summary should reflect that, and this should be tested in every core theme

Many of the problems with Dropbutton will be fixed with the new Splitbutton element, if that issue lands: ✨ Add new Splitbutton render element to eventually replace Dropbutton Needs work .
Converting to Splitbutton will not be something that can happen immediately after it is committed, so addressing Dropbutton issues is still valuable - but also be aware one of the reason Splitbutton work even happened is because it's proven difficult to implement Dropbutton improvements that don't introduce regressions or other problems.

Just realized an additional issue, the dropbuttons close automatically half a second after losing focus. This seems confusing for screen readers / magnifiers, even after fixing the aria attributes to match the state, you wouldn't necessarily expect it to change. Also the buttons don't open on focus/hover, so it seems inconsistent to have them close automatically on focusout

I haven't tested with a screen reader yet @camilledavis, but definitely agree that the behavior in losing focus is a problem. It is a relatively small area. Folks shouldn't have to keep it over that small spot to continue reading the menu.

I attached a movie of the experience.

I can confirm in the /admin/structure/taxonomy

That the focus state is not announced to the screen reader user.

Here's a simple recording with VoiceOver.

camilledavis → closed merge request !3861

Can issue summary be updated please. Also screenshots added to it

If changing aria labels and text can we add some assertions somewhere to make sure they don’t break in the future.

Sure, where should it go? I'm guessing Nightwatch/Tests/ and make a file called dropbuttonTest.js?

Screenshots appear to have been added and issue summary updated

Believe this is ready for accessibility.

I've tested MR5231 and created a short video (see dropbutton.mp4 - recorded on macOS 14.5 and safari 17.5 with voiceover). In general the first point of the proposed solution looks good, the open and closed state are commenunicated, that's perfect.

In regards of the second point reducing the drop button label from "list additional actions" to just "additional actions" is a good choice, i agree to that. The only thing i wonder is if it would make sense to append the context the button is in, front load "additional actions" and then append the context. that way a screenreader user could jump off at any time but still has the option or in case the person has a small working memory to reassure it is the correct button in the correct context (also if someone navigates by the rotor). the edit button as well as the delete option already provide that context while the additional actions button and translate option do not? I would consider it out of the scope for this issue but moving "providing a context" into a follow up might be a reasonable step, what do you think?

In regards of the third point, keeping the dropdown up when focus and hover are out i consider a good thing but as soon as another drop button is expanded it looks and feels odd (check dropdown.mp4)? wouldnt it make sense to collapse a drop button as soon as another is expanded? would be the same pattern that was used for the subnav of top level menu items in the admin_toolbar?

and @camilledavis you've suggested to allow the user to collapse the drop button by pressing ESC in #4 ✨ Dropbutton widget not accessible to screen readers Needs review . I would +1 that option.

Thanks @rkoller this is great. I'd like to see this patch include Ralf's suggestion to collapse the first drop button as soon as another drop button is expanded. We don't want to introduce an accessibility issue for keyboard only users, by fixing an issue for screen reader users.

I would say that from Ralf's demo that the patch would currently violate SC 2.4.11: Focus Not Obscured (Minimum) (Level AA).

Let's open up a follow-up item about the drop button label, as suggested by Ralf.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Can we get someone to re-roll this patch?

Hey @mgifford, I am not seeing an conflicts so no need to re-roll I think till we get traction on this.

Hi @mgifford, I tested the MR!5231, the button state has been communicated well. But I found one issue regarding the dropdown button toggle state. When focusing on the dropdown button for the first time the screen reader reads as additional actions, button collapsed and additional actions, button expanded when the dropdown button list has been expanded. But then after when focusing on dropbutton it always announces as additional actions, button expanded even after the list has been collapsed.
I've resolved this issue. Now the button state is communicating additional actions, button expanded when the dropdown button list expands and additional actions, button collapsed when the dropdown button list has been collapsed. Please review the changes.

Hi @mgifford, attached the before and after video clips for the screen reader dropdown expanded and collapsed announce issue.

Appears to have test failures now.

In the JS it looks like a good amount of additional logic is going into supporting aria-controls, but given that only the JAWS screenreader supports it, and a trusted A11y expert has deemed aria-controls to be poop. Since aria-controls support is so limited it is not likely causing any AT problems, but it may not justify the additional complexity.