Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
I am creating this issue against the views module, but maybe the "component" shouldn't be views since the issue regards dropbutton...
The "List additional actions" button shown in the "dropbutton" widget needs two important accessibility improvements:
- After being clicked and showing the additional actions, the button label should become "Hide additional actions" (since clicking the button again will hide the additional actions);
- The button should have some help text (as it happens using the "title" attribute for a link) to let an user understand what the button does (I think also this text should be different when additional actions are shown or not to reflect the button label);
Comments
Comment #1
webchickThese sound like good improvements to make, but according to Priority levels of issues, I do not see how they render the system completely non-functional without them.
Comment #2
nod_tag
related #1799498: Improve dropbutton
Comment #3
Bojhan CreditAttribution: Bojhan commented@falcon3 Can you maybe give a little more context seems like you are suggesting two quite different fixes. Maybe we should split those up. The first one seems super easy, and something we should do all over core? Do we?
Comment #4
falcon03 CreditAttribution: falcon03 commented@Bojhan: these improvements relate to dropbutton wherever is used.
I think that these two improvements are really easy to implement (I haven't done them because I don't know Javascript).
The first improvement regards the "list additional operations" string. In fact, in my opinion it would be more understandable (also from a sighted user perspective I suppose) to see the string "Show additional operations" (when additional operations are hidden). When the button is clicked and additional operations are shown, the string should become something like "Hide additional operations", since clicking the button will do exactly this task...
The second improvement regards introducing a simple help text for the button. I haven't checked the markup yet, but if the button is created using a link with the "button" role this task would be as easy as setting up properly the "title" attribute.
Maybe you're right and we should split these two issues, since thinking again to this second problem it seems not-really-a-problem. But IMO the first problem is very, very important also from a sighted user perspective.
Comment #5
xjmI also discovered in #1830822: Split the Views UI listing into two tables for enabled and disabled that the highlight indicating focus when navigating with the keyboard is quite hard to see with the dropbutton. The dotted line almost disappears around the action link name in both FF and webkit, and in FF, the focus indicator around the down arrow (for the additional operations) is not visible at all. I had to tab back and forth a lot to be sure I was activating the correct control.
Not sure how to dice up the issues, but these are bugs.
Comment #6
xjmComment #7
xjmComment #8
xjmSorry for all the noise. Let's do this and file separate issues for each of the above things.
Comment #9
dead_armChild issue for dropbutton color contrast #1858206: Dropbutton background with gradient does not meet WCAG AA standard
Comment #9.0
dead_armcorrecting some mistakes
Comment #10
LewisNymanRelated: #1989470: Dropbutton style update for Seven
Comment #11
LewisNymanComment #17
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedThis issue has been open for a long time without progress. There's a much more detailed plan forming at #1899236: Add new Splitbutton render element to eventually replace Dropbutton, so I'm closing this as outdated.
To address the original points raised by @falcon03:
aria-expanded="true|false"
.aria-expanded
provides more familiarity for the user.lang="en"
), they might hear "More actions, bouton, étendu". The button text is English from Drupal, but the role and state are conveyed in the host OS language. (Don't trust my French, I just grabbed those words from a dictionary.)aria-expanded="true|false"
in conjunction witharia-haspopup="menu"
, and implement the full menu button pattern from the WAI-ARIA Authoring Practices. I'm not convinced we need all of it though;aria-expanded
will probably suffice.There is a specific issue to address this now - #2893663: Dropbutton should report open/closed state to assistive technology.
Also, @xjm's point in #5:
I've added focus indicator improvements to the plan at #1899236: Add new Splitbutton render element to eventually replace Dropbutton. The ones we have now are just too weak. Technically, you can pass WCAG SC 2.4.7 Focus Visible even if the focus style is weak. This is a bit of an oversight in WCAG 2.0, so WCAG 2.1 has clarified the need for clear focus styles in SC 1.4.11 Non-text contrast.