Add explanatory text on disabled checkboxes on modules page

nice summary, uses the template and everything. :)

screenshots before and after would be awesome

I think we might be trying to avoid using the word disable ...

how about instead of
Disable this module by visiting the Uninstall page.
Uninstall this module on the Uninstall page.

It sounds repetitive... but people who know it already will just go there, and people who expect clicking on the checkbox to do something will know that uninstalling is the thing to do.

But I'm ok either way really.

I dont think we need a test for this... as long as it doesn't fail. I think this is an improvement.

No unrelated changes. rtbc

I agree with @YesCT I think we got rid of the enable/disable terminology (or at least wanted to) because that is not a possibility in Drupal 8 anymore and uninstall/install has much more consequences. As a foreign speaker not sure how to avoid the word repetition though.

Updated the message.

Thanks @shashikant_chauhan and @quicksketch.

+1 for making this clearer somehow; I've seen people claiming modules can't be uninstalled at all in D8 because the checkbox is disabled and they don't find the tab.

I also think having the disabled checkbox at all is part of the problem, so the complete fix for this would be to redesign the page so it doesn't rely on checkboxes that you can never uncheck. We shouldn't block a small improvement like this on that, but in the longer term we should actually fix the problem rather than adding help text to work around it. #2035079: [PP-1] Figure out what to do with the install/uninstall modules page is the issue for that, so adding it here in case anyone else has the same thought.

Having this text at all is a definite improvement. I'd like to double-check the accessibility of the title attribute strategy, though, so tagging for accessibility review and setting NR pending that signoff.

Thanks!

Thanks for tagging this. Here's my accessibility review.

Summary:

• The title attribute is bonus content for sighted pointer (hover) users only. It's not suffiicient for content we want all users to have access to.
• Regression-wise, this doesn't make actually any thing worse for most users, including keyboard-only and assistive-tech users.
• As a new feature however this doesn't doesn't count as inclusive design. Many groups of users will not be able to perceive it all. Others may be have a frustrating experience - screen magnifiers are particularly impacted.
• In my view the title attribute isn't sufficiently inclusive/robust to meet our accessibility gate.

Further details:

The following groups of users will NOT be able to perceive the tooltip content at all (not exhaustive - there are probably others I'm unaware of):

• Sighted keyboard-only users (without a screen reader).
• Screen reader users. Many screen reader + browser combinations will use announce a title attribute, but only as a fallback where no associated is available. In this case, the checkbox does have an associated <label for>, so that will be used in preference to the title attribute.
  For example, ChromeVox announces: "Automated cron, tickbox, ticked, disabled". This is expected behaviour per the W3C HTML to Platform Accessibility APIs implementation guide.
• Users of any other assistive tech which relies on information from the platform accessibility APIs. Essentially, a generalization of the screen reader experience above. The <label for> will be used as the accessible name, and the title attribute will be ignored. Examples could include:
  • Some switch access scanning configurations (a.k.a. switch control in Apple-land) can provide command palettes.
  • Some screen readers offer additional tools to summarize (and navigate) form controls on a page.
• Touch screen (finger) users. Most touch screens won't display tooltips, because they aren't able to produce a hover event. Note that some touchscreen + stylus devices can produce a hover event (e.g. Samsung galaxy Note with S-Pen). Other devices may be able to do this with fingers eventually, e.g. via "force-touch" pressure sensing, but I have no idea whether anyone has implemented this yet. In the foreseeable future, assume the vast majority of touchscreen users won't be able to perceive the tooltip.

Some groups of users will be able to perceive the tooltip content, but experience difficulty (again, not an exhaustive list):

• Users with low mouse pointer accuracy due to low vision, motor impairment, etc. The current browser implementations only show the tooltip while the pointer is over the checkbox element. This has a small target size, so it can be difficult to get the tooltip to appear. Note that operating the checkbox can be done by clicking the visible <label> text, so there's a discrepancy between the target sizes which will check the box versus activate the tooltip.
• Speech control users will typically operate a checkbox by saying e.g "click automated cron" - there's no need to use a mouse pointer for this. Some speech control (e.g. Dragon) provides commands to move a mouse pointer, so a user can technically trigger a hover event, but it's tedious. Since checkboxes can be operated without moving the pointer, the tooltip isn't very discoverable for speech control users.
• Screen magnifier users can hover over the checkbox, but the tooltip can overflow the viewport. To read the whole tooltip, you'd need to move the move pointer, which in turn makes the tooltip disappear. Screen magnifier set-ups vary considerably, but we should assume that lots of users will find this frustrating. Here's a screenshot of a tooltip on a 1920x1080 display, using the screen magnifier which is built in to KDE Plasma Desktop. The phrase "uninstall page" is truncated by the viewport edge:
  

If we are committed to redesigning the modules page (#2035079: [PP-1] Figure out what to do with the install/uninstall modules page) then I might consider this an acceptable temporary usability improvement, on the road to a more inclusive design. That issue hasn't reached a consensus though, so I think it's premature to carry out this one.

Most likely there are some ways we can improve this. Maybe we won't win them all, but if we can fix or mitigate problems for a number of affected user groups, then I'll be more warm about this. I'll have a think.

@andrewmacpherson yeah this seems to come down to "small improvements for some users" being better than "no improvement for any user at all". It seems like this does not regress at least. I agree if there are better ways to improve this for more users, that would be nice, but definitely would not condition this on a commitment to #2035079: [PP-1] Figure out what to do with the install/uninstall modules page.

So, I've started using d8 after many many years of using d7, and encountered this issue the same as everyone has. I found this issue thread (and the related 2035079 one). However the last comment here is from almost a year ago now.

So in the meantime before this is addressed in core, here's a new d8 module you can try out: module_checkbox_clean

It doesn't really make any major changes, but it does at least help out a bit with the UI on the /admin/modules page.

I think this still makes sense. As most people have pointed out already, this isn't an improvement for everyone but introduces no regressions.

Patch still applies to 10.1 with some fuzz. Added an updated patch for 10.1 and kicking off tests.

Hi @DanielVeza, Applied your patch successfully and i got the solution. It was added a simple title attribute . Need RTBC+1.

Can we also add aria-label. May help expand the users it will help.

Also leaning towards the idea if a simple assertion could be added anywhere to verify the attributes are present.

I have added "aria-label" to the checkbox, attached interdiff for same.

Assertion still needs to be added.

Thanks look good! And so we don't break it wonder if we can a 2 line assertion somewhere for those values.

We really should be seeing this use of title as being a form of technical debt. It just isn't an inclusive approach. I am adding a link to the need to actually build a better solution for tooltips. The disabled text could go in the description field rather than the title. It isn't a WCAG failure though, just not a great pattern to repeat.

There's another issue trying to solve the same problem with different approach: #2890791: Improve usability of disabled checkboxes on module listing page.