List view: the 'sticky' information is only visual

[afercia]

Description

In the List view, some icons may be shown to provide information about some block properties, for example:

• when the block is locked.
• when the block is sticky

Screenshot:

While for the 'locked' state a text (locked) is appended to the block item aria-label, there's no textual information for the 'sticky' case.

As such, there's no parity between the visual information provided to sighted users and the textual information provided to users with no vision or low vision or users who don't recognize icons meaning.

Ideally, this kind of important information should be provided by the means of visible text.

At the very least, the 'sticky' state should be communicated by the means of some visually hidden text or description

Step-by-step reproduction instructions

• Go to teh post editor.
• Add a group block with a paragraph.
• First, make the group block sticky.
• Then, make the group block locked.
• Open the list view.
• Observe the group block item has two icons: sticky and lock.
• Inspect the source.
• Oserve the aria-label of the group block is: Group (locked).
• Onserv there's no textual information of any type about the sticky state.

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

[t-hamano]

I think that in addition to the sticky information, the anchor text also needs to be conveyed to the screen reader. I'm at a loss as to what is the appropriate way to convey this when these things are combined...

[afercia]

Thanks @t-hamano. Yes I wanted to investigate other potential icon / things that may be rendered within the list view items. The anchor is a good one. I also want to investigate the image previews.
Any more potential things that may be shown there you can think of?

[t-hamano]

Looking at the List View implementation, there are four pieces of information that may be displayed in addition to the block name:

• Anchor text
• Sticky icon
• Image thumbnails
• Locked icon

Currently, only theGroup block supports sticky position, but image thumbnails will not be displayed in this block. However, assuming that image thumbnails are also supported in the future, it is possible that all four pieces of information will be displayed.

In that case, will it be a long label like Group (Locked, sticked, anchor text: test, has 4 images)?

[afercia]

Regarding the 'anchor' information, I wonder how displaying truncated text that doesn't actually help understand what the anchor is, is any useful for users. Also, there's potentially really too much stuff and info provided within the list view items.

Overall, I think hiding or truncating text 'just to make it fit into the design` is less than ideal. Content should never be hidden. The interface should be designed around the content and not vice-versa.

Each list view item can get to a state where the UI is really not useful. Example screenshot:

[t-hamano]

I agree that depending on the block settings, the current list view displays too much information. We may need to reconsider the information that should be displayed in the list view and its ideal state.

cc @gutenbergplugin

[afercia]

With the new Bindings API, there's now a new information provided by only icon: Bound blocks will display this purple icon:

There is no textual information in this case as well.

From a techinical perspective, the current code implementation appears to be less than ideal:

gutenberg/packages/block-editor/src/components/list-view/block-select-button.js

Lines 290 to 321 in f7070e8

	{ isConnected && canBindBlock( blockName ) && (
	<span className="block-editor-list-view-block-select-button__bindings">
	<Icon icon={ connection } />
	</span>
	) }
	{ positionLabel && isSticky && (
	<Tooltip text={ positionLabel }>
	<Icon icon={ pinSmall } />
	</Tooltip>
	) }
	{ images.length ? (
	<span
	className="block-editor-list-view-block-select-button__images"
	aria-hidden
	>
	{ images.map( ( image, index ) => (
	<span
	className="block-editor-list-view-block-select-button__image"
	key={ image.clientId }
	style={ {
	backgroundImage: `url(${ image.url })`,
	zIndex: images.length - index, // Ensure the first image is on top, and subsequent images are behind.
	} }
	/>
	) ) }
	</span>
	) : null }
	{ isLocked && (
	<span className="block-editor-list-view-block-select-button__lock">
	<Icon icon={ lock } />
	</span>
	) }

• All icons have no textual alternative information.
• The Sticky icon is the only icon that is supposed to have a Tooltip. Not sure why the Tooltip component is used only for this icon.
• Tooltips don't work with icons anyways, so it appears this hasn't been tested sufficiently. Edit: see better explanation in the following comment.
• The image preview is a background image annd it's also ARIA hidden.

[afercia]

Tooltips don't work with icons anyways,

Turns out the tooltip on the 'sticky position' icon stopped working after #57202 so this is a regression from WordPress 6.4 where this tooltip does work. Cc @ciampo not sure this is the intended behavior of the check for nested tooltips.

Screenshot:

We should remove the tooltip anyways because:

• It is actually set on an Icon inside a link. Making the tooltip work again would produce a focusable element inside a link ie.: two nested focusable elements, which is far from ideal. This can be checked in WordPress 6.4 where the tooltip works and Ariakit adds a tabindex="0" to the SVG icon.
• As mentioned in other issues, the fact Ariakit adds a tabindex="0" to any element where a Tooltip is set to is far from ideal because it will make unsemantic elements with tooltips focusable e.g. focusable div elements and such.
• Tooltips should only be used to visually expose an interactive control name. They should never be used for descriptions.
• There is no textual information anyways so the Tooltip is pointless.

[ciampo]

Sorry for the delay, still catching up after having been AFK for a while.

@afercia as you point out, Tooltip should not be rendered inside an interactive element (an anchor tag). This is an incorrect use of the component, which leads to inconsistent and unexpected results. I've opened #63850 to remove it.

[t-hamano]

Are there any other issues that need to be addressed regarding this issue?

• Block Bindings icon has been removed from the list view: #59477
• Do we need to provide any information to images?