Improve usability of disabled checkboxes on module listing page

omkar.podey → made their first commit to this issue’s fork.

kunal.sachdev → made their first commit to this issue’s fork.

This is failing a Nightwatch test:

06:26:42 [Tests/Js Displace] Test Suite
06:26:42 ────────────────────────────────────────────────────────────
06:26:42 - Connecting to chromedriver-jenkins-drupal-patches-205224 on port 9515...
06:26:42 
06:26:42   Using: chrome (106.0.5249.103) on LINUX.
06:26:43 
06:26:43 ℹ Connected to chromedriver-jenkins-drupal-patches-205224 on port 9515 (265ms).
06:26:43 - Loading url: http://php-apache-jenkins-drupal-patches-205224/subdirectory
06:26:45 
06:26:45   ℹ Loaded url http://php-apache-jenkins-drupal-patches-205224/subdirectory in 498ms
06:26:45 - Loading url: http://php-apache-jenkins-drupal-patches-205224/subdirectory/user/reset/1/1695641205/ZcLBseK-n7HNz7ZvfIavUAwgecWaw2TwTn_f1veVSRs/login
06:26:46 
06:26:46 
06:26:46   ℹ Loaded url http://php-apache-jenkins-drupal-patches-205224/subdirectory/user/reset/1/1695641205/ZcLBseK-n7HNz7ZvfIavUAwgecWaw2TwTn_f1veVSRs/login
06:26:46  in 377ms
06:26:46 - Loading url: http://php-apache-jenkins-drupal-patches-205224/subdirectory/admin/modules
06:26:46 
06:26:46   ℹ Loaded url http://php-apache-jenkins-drupal-patches-205224/subdirectory/admin/modules in 993ms
06:26:47   ✔ Element <form.system-modules [name="modules[js_displace][enable]"]> was visible after 575 milliseconds.
06:26:48   ✖ NightwatchAssertError
06:26:58    Timed out while waiting for element <form.system-modules [name="modules[js_displace][enable]"]:disabled> to be present for 10000 milliseconds. - expected "found" but got: "not found" (10422ms)
06:26:58 
06:26:58     Error location:
06:26:58     /var/www/html/core/tests/Drupal/Nightwatch/Commands/drupalInstallModule.js:
06:26:58     ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
06:26:58      26 |       // Wait for the checkbox for the module to be disabled as a sign that the
06:26:58      27 |       // module has been enabled.
06:26:58      28 |       .waitForElementPresent( 
06:26:58      29 |         `form.system-modules [name="modules[${module}][enable]"]:disabled`,
06:26:58      30 |         10000,
06:26:58     ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
06:26:58 
06:26:58 
 

As mentioned in #26 ✨ Improve usability of disabled checkboxes on module listing page Needs review also, it'd be good to get usability/accessibility feedback before working on it more.

Issue summary hasn't been updated in some time. If that could be updated with today's template.

Also screenshots should be included there.

Will need a change record for the change to the templates. Also does stable9 or starterkit need to be updated as well?

Definitely will need usability, with the checkboxes missing on the modules page first assumption was something is broken.

Updated the issue summary.

I was testing the MR locally and i noticed that the installed module section does not announce the name of the module for screen readers but it does for the rest of the module groups.It only describes the summary about the module while navigating with the help of tab button. Can we have an element that announces the name of the module just like the checkbox in other module groups?

I discussed regarding #49 ✨ Improve usability of disabled checkboxes on module listing page Needs review with @lauriii and he said it's fine that the installed module section does not announce the name of the module for screen readers as they can navigate within the table/list to read the module name.

Removing screenshot tag.

Tested it manually, everything is working as expected.Thanks for the clarification on #49 @kunal.sachdev and @lauriii.Marking it RTBC.

I have proposed this issue for a usability review.

Other than that, I think this is still NW because the tests are still missing (see #5, #17). I think we should add at least a test to check if the installed module is really in the Installed Modules group. Thanks!

Added a new test.

Still needs a CR.

Create CR [#3393855].

This looks good to me. We're just re-implementing existing/tested patterns. Happy to see this in Core.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-10-13 Needs work . The direct link to the recording is: https://youtu.be/Kgz01Pn4Dl0?si=Td_HxTE-0o1413Gp&t=2455

For the record, the attendees at today's usability meeting were @AaronMcHale, @anmolgoyal74, @benjifisher, @rkoller, @simohell, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

We've discussed the issue already about a month ago but at the end of the meeting we forgot to agree on who will comment on the issues as the meeting time had already passed. Apologies for that. :( In general the group agreed that the issue fixes the usability concerns about disabled checkboxes but at the same time it introduces a few new problems. The points we've noticed during our discussion:

1. The key question we've asked ourselves was is it helping to move the list of installed modules to a new group (which functions and behaves slightly differently) on top of the existing groups of uninstalled modules? You get a flat list of all installed Core and contributed modules. While uninstalled modules are grouped into Core, Core (Experimental), Field Types, Migration, Multilingual, Web services, or any group created by a contributed module.
That meta data is not available for installed modules. That way the list of installed modules got more difficult to comprehend, orient, and navigate in. The user has to remember the module name to either filter for or expand the Installed modules group and scroll to the corresponding position in the alphabetic sort order. There is no way to filter or visually search in the proximity of a group within the Installed modules group in case you only remember the thematic context a module is in but not its exact name.
So overall the state of the MR might work for a person installing a module, but a few days/weeks/months down the road or in case someone else is joining or taking over a site, governance might pose potential challenges and an increased cognitive load.

=> An alternative approach that was voiced was not to move installed modules to a dedicated new group, instead the list should be kept as is - installed and uninstalled modules grouped and sorted like right now. And the idea is to add a filter to the filter section. To provide the option to filter the list of modules by installed, uninstalled or no filter applied.

2. The behavior of the Show all columns button is unexpected.

Desktop (widescreen):
After expanding the Installed modules group if you click the Show all columns button it simply disappears. There is no apparent change to the visual presentation of the list of installed modules nor any way aside from a reload of the page to make the button reappear. In contrast the uninstalled module groups underneath don't contain nor show those Show all columns buttons.

Desktop (narrow screen), mobile (simulated) on MacOS Sonoma in Safari 17.1 as well as on a iPhone 14
If you click the Show all columns button the Hide lower priority columns is shown. But no matter which button is pressed, only the module name is shown, the description stays hidden for each of the states. There is no apparent difference between both states.That behavior also applies for Microsoft Edge where we've tested that as well.

And in regards of the toggle functionality and the changing button labels. Leonie Watson outlined the problem that switching button labels poses to screenreader user in this video for Smashing Magazine about how a screen reader user surfs the web → . It might be good to open up a follow up issue and improve the markup and functionality of that button in Core in general.

3. Uninstalled modules have a checkbox and an associated label element providing the module name. For installed modules that checkbox got removed and the module name is just wrapped in a span element now. For screenreader users that means the module name aka context might go unnoticed or is at least hard to spot. One would have to go stepwise through each table cell (with VoiceOver for example by pressing VO and the arrow key). If you step through the interface with just the tab key (see installed_modules.mp4), only the descriptions are announced, which in most cases don't contain the module name. If you use the rotor, in for example VoiceOver (also see installed_modules.mp4), you are also unable to directly spot any module names after the Installed modules group in any of the rotor sections.

We've discussed the whole problem space of /admin/modules in the context of several related issues over the course of the last months and had the clear consensus that things should be moved in small steps. In particular, with Project Browser on its way into Core, this will significantly change the experience for many users, with less experienced and new users likely opting to use Project Browser. While we do recognize that some users will continue to use the Core module list as is, we believe that the approach of smaller incremental improvements makes more sense. With the points listed above and Project Browser on the horizon, our consensus was that the changes this MR introduces are probably not the best steps to take at this point.

In the short term the option might be to tackle concerns raised in this usability meeting. But the more sustainable long term solution might be do some research about the current state of Project Browser and potentially Automatic Updates first to learn about the constraints they introduce and which needs they have and combined with an assessment of the current state of the /admin/modules draw an informed decision which exact route to take.