Data views: Make checkboxes always visible

[afercia]

Description

In the data views, the checkboxes to select items get only visible on hover or focus. While I understand the intent of making the UI look cleaner, I think the current pattern doesn't help usability and accessibility. Instead of keeping prioritizing visual cleanless as proposed in #59128 and making all controls only visible on hover or focus, I think a better, more understandable, predictable, and self-explanatory user interface needs to make everything visible by default.

Screenshot:

• Prioir accessibility feedback on several issues and pull requests always reported that controls that continously appear and disappera are an inherent accessibility problem. It doesn't matter whether they appear and disappear because they are conditionally rendered or because their visibility is toggled after user interaction. The appearing / disappearing isn't a good inclusive pattern and should be avoided.
• Cognitive load: the UI isn't self-explanatory: users have to first interact with the interface to see and understand what they can do with the UI.
• The checkboxes appear when hovering on any part of a row. That's confusing because the Title text looks like the checkbox label. When hovering the title, the gray text of the title looks like a <label> element. The mouse cursor becomes a pointer. As a useer, I would expect that clicking the title select the checkbox. Instead, the title is a link to the item details (in the screenshot above it's a link to the page). By making the checkboxes always visible, it would be more intuitive that checkbox and title are two separate controls with two different purposes.

Step-by-step reproduction instructions

• Go to Site Editor > Pages > Manage all pages.
• Observe the table with the list of pages.
• Observe the checkboxes aren't visible.
• Hover a table row or use the keyboard to navigate within the table.
• Observe the checkboxes get only visible on hover and focus.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[richtabor]

I think a better, more understandable, predictable, and self-explanatory user interface needs to make everything visible by default.

While visibility of interface elements can enhance usability, making everything visible by default is almost always not the best approach.

Overloading a user interface with too many visible elements at once can lead to clutter, overwhelming users rather than aiding them. It's important to balance visibility with simplicity and to prioritize the presentation of controls based on user tasks and contexts. Effective interface design often involves selectively showing the most relevant options and utilizing progressive disclosure to reveal more options as needed. This approach can help users process information more effectively, making the interface not only more manageable but also more intuitive to navigate.

[afercia]

making everything visible by default is almost always not the best approach.

Do you have any data, research, and more importantly any user testing to backup this statement? Thanks.

[SaxonF]

making everything visible by default is almost always not the best approach.

Do you have any data, research, and more importantly any user testing to backup this statement? Thanks.

The benefits of progressive disclosure are pretty well documented, and I see this as a form of that. Showing actions on hover is a pretty standard pattern too, see gmail for example.

[afercia]

The benefits of progressive disclosure are pretty well documented,

Accessibility guideleins are very well documented as well, since 1999.

[TimothyBJacobs]

We recently shipped data views in one of our apps and got similar feedback. From one user directly:

I noticed one thing with the application. When updates are displayed, the checkboxes only appear when I move the mouse over the lines. This is not ideal for mobile devices (e.g. iPad) as you often don't use a mouse.

[t-hamano]

As far as I know, on mobile viewports, the Grid layout doesn't have a way to select multiple items. I think this is the most important issue.

On the other hand, in the Table layout, checkboxes are always visible:

At the very least, I think the checkbox should always be visible in the mobile layout.

Example implementation:

gutenberg/packages/dataviews/src/dataviews-layouts/table/style.scss

Lines 82 to 88 in f1f5988

	@media (hover: none) {
	// Show checkboxes and quick-actions on devices that do not support hover.
	.components-checkbox-control__input.components-checkbox-control__input,
	.dataviews-item-actions .components-button:not(.dataviews-all-actions-button) {
	opacity: 1;
	}
	}

[karthick-murugan]

At the very least, I think the checkbox should always be visible in the mobile layout.

Example implementation:

gutenberg/packages/dataviews/src/dataviews-layouts/table/style.scss

Lines 82 to 88 in f1f5988

@media (hover: none) {
// Show checkboxes and quick-actions on devices that do not support hover.
.components-checkbox-control__input.components-checkbox-control__input,
.dataviews-item-actions .components-button:not(.dataviews-all-actions-button) {
opacity: 1;
}
}

@t-hamano - Can I update my PR such that the mobile layout has the checkbox visible and keep as it is for other layouts? Please advice

[t-hamano]

@karthick-murugan I've read through this issue from the beginning and it seems like we haven't reached a consensus yet. I think we need some more discussion on this issue before we move forward with #67874.

[afercia]

Given the Data views will be widely used in the future I think establishing an accessibility princniple here that the checkboxes must be always visible is a very important point. I'd like to hear from other contributors from the Accessibility team @joedolson

Aside: I would appreciate a new Github mention handle to be considered for accessibility folks s,g. @WordPress/gutenberg-accessibility.

[joedolson]

What I'm failing to see here is any argument in favor of hiding the checkboxes. There's a general comment on "showing the most relevant options and utilizing progressive disclosure to reveal more options as needed", and that's completely reasonable. The debate here, I think, is whether or not the checkbox is an interface element that should be hidden - e.g., is it a "less relevant option" in this view?

@SaxonF mentions Gmail as an example; but Gmail is an application that shows the checkbox persistently, so that seems like an argument in favor of visible checkboxes.

In my opinion there are two basic actions that are the primary actions in these views: select a group of items for bulk manipulation, or navigate to a single item. Neither of them should have primacy over the other; users are just as likely to need to navigate to one item as they are to need to perform a bulk action. To that effect, those two functions should be always apparent.

[karthick-murugan]

Thank you for the discussion and valuable insights. Based on the points raised, particularly regarding the importance of both bulk selection and single-item navigation being equally accessible, I believe making the checkboxes visible by default is the most user-friendly solution.

As mentioned by @joedolson, Gmail serves as a good example where checkboxes are persistently displayed, reinforcing the argument for visibility. By keeping the checkboxes always visible, my PR ensures that both primary actions—bulk selection and individual navigation—are consistently available to users without requiring additional steps or progressive disclosure.

If there are further suggestions or refinements you'd like to see in the PR, I'd be happy to work on them. Looking forward to the team's feedback!