Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List view: the 'sticky' information is only visual #59409

Open
afercia opened this issue Feb 27, 2024 · 11 comments
Open

List view: the 'sticky' information is only visual #59409

afercia opened this issue Feb 27, 2024 · 11 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Package] Block editor /packages/block-editor [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Feb 27, 2024

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:

Screenshot 2024-02-26 at 14 34 26

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

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Block editor /packages/block-editor labels Feb 27, 2024
@t-hamano
Copy link
Contributor

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

image

@afercia
Copy link
Contributor Author

afercia commented Feb 29, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

afercia commented Mar 5, 2024

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:

Screenshot 2024-03-05 at 16 48 33

@t-hamano
Copy link
Contributor

t-hamano commented Mar 6, 2024

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 afercia added the Needs Design Feedback Needs general design feedback. label Mar 11, 2024
@afercia
Copy link
Contributor Author

afercia commented Mar 11, 2024

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

Screenshot 2024-03-11 at 12 37 52

There is no textual information in this case as well.

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

{ 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
Copy link
Contributor Author

afercia commented Mar 11, 2024

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:

Screenshot 2024-03-11 at 14 47 35

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
Copy link
Contributor

ciampo commented Jul 23, 2024

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
Copy link
Contributor

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?

@ciampo
Copy link
Contributor

ciampo commented Jul 30, 2024

@afercia may be AFK right now, but looking through his feedback, I think that a good solution could be to make sure:

Do we already have descriptions for all possible icons that can be displayed in the list view?

@t-hamano
Copy link
Contributor

Thanks for the reply.

I re-read this issue and it seems that the information other than the block name displayed in the list item, and whether it is read out properly, is as follows:

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

So it might be best to leave this issue open for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Package] Block editor /packages/block-editor [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants