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:

  1. 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);
  2. 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

webchick’s picture

Category: bug » task
Priority: Critical » Normal

These 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.

nod_’s picture

Issue tags: +JavaScript
Bojhan’s picture

Component: views_ui.module » markup

@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?

falcon03’s picture

@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.

xjm’s picture

Category: task » bug

I 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.

xjm’s picture

Title: dropbutton "list additional actions" accessibility should be improved » dropbutton "list additional actions" accessibility issues
xjm’s picture

Issue tags: +VDC
xjm’s picture

Title: dropbutton "list additional actions" accessibility issues » [meta] Dropbutton accessibility issues

Sorry for all the noise. Let's do this and file separate issues for each of the above things.

dead_arm’s picture

dead_arm’s picture

Issue summary: View changes

correcting some mistakes

LewisNyman’s picture

LewisNyman’s picture

Issue tags: +frontend

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

Status: Active » Closed (outdated)

This 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:

  1. Rather than change the button text each time it is opened/closed, we can leave the button text static, and convey the open/closed state using aria-expanded="true|false".
    • A screen reader user will hear something like "More actions, button, expanded". The role and state are machine-readable properties, which the assistive tech understands. Instead of using UI strings provided by Drupal, the state is conveyed using phrases from the host OS platform. So using aria-expanded provides more familiarity for the user.
    • This is well supported nowadays, though it might not have been a reliable option 6 years ago :-)
    • It has the added bonus that screen readers can convey this state using UI language of the host OS platform, rather than Drupal's (author-provided) strings. So if a French speaker (with a French OS and screen reader) visits an English Drupal page (with 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.)
  2. Like @bojhan, I'm not quite sure how the second point is different from the first. We might consider using aria-expanded="true|false" in conjunction with aria-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.