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

Site editor: List view: incorrect labeling of navigation links #59369

Closed
afercia opened this issue Feb 26, 2024 · 5 comments · Fixed by #59370
Closed

Site editor: List view: incorrect labeling of navigation links #59369

afercia opened this issue Feb 26, 2024 · 5 comments · Fixed by #59370
Assignees
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Block editor /packages/block-editor [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Feb 26, 2024

Description

In the Site Editor > Design > Navigation > Any navigation menu, the navigation links visually show the link label, that is the textual label users enter when they create a linb.

However, the aria-lable of each link is actually the navigation link type, ie. 'Page Link', 'Custom Link', 'Submenu'.

As such:

  • The visual labeling and the actual accessible name mismatch.
  • Screen reader users don't have any clue what the navigation link actually is. Only the link type is announced.
  • Speech recognition software users can't activate the links because of the label / name mismatch.

It is worth reminding that aria-label overrides any textual content. As such, these labels aren't really useful for users, for example:

  • aria-label="Page Link"
  • aria-label="Custom Link"
  • aria-label="Submenu"

Screenshot:

Screenshot 2024-02-26 at 10 05 55

In this context, 'Page Link', 'Custom Link', 'Submenu' etc. aren't meaningful names for these items.

Instead, in the Post editor list view, the block type makes more sense. However, the items in teh list view can be many things:

  • blocks with default names
  • blocks with custom names (renamed by users)
  • synced patterns with user provided names
  • navigation links with user provided labels (the link text)

All these cases need the item aria-label to match the text that is visually displayed as that is the text that gives users the correct information about what they are going to edit.

It appears the List View items labeling mechanism hasn't been tested enough in the context of the Site editor navigation links, as the current labeling is clearly insufficient to provide any useful information to users.

Additionally:

Each item may provide additional information like the 'sticky' status or the 'locked' status. These need improvements as well and I will open a separate issue. For now, I'd like to address also the 'Options' ellipsis button. To me, these aren't 'Options'. The concept of options is about settings or preferences, while the dropdown menu provides actions. Also, in other context this ellipsis button is labeled 'Actions', for example in the patterns cards. For a more meaningful naming and for consistency I'd like to rename this button to 'Actions' and simplify it by removing the part 'for %s'.

Step-by-step reproduction instructions

  • Use a screen reader, for example VoiceOver with Safari.
  • Go to the Site Editor > Design > Navigation > Any navigation menu.
  • Navigate through the list view items in the navigation panel.
  • Observe the items are announced with their navigation link type rather than their link text.

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). [Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Package] Block editor /packages/block-editor labels Feb 26, 2024
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Feb 26, 2024
@getdave
Copy link
Contributor

getdave commented Mar 18, 2024

This is an accessibility bug identified during the RC period. For this reason I believe it should be included in the WordPRess 6.5 release during the RC period.

I'm putting it on the board for now and marking the related PR with the backport label.

Do you concur @youknowriad @fabiankaegy @annezazu?

@youknowriad
Copy link
Contributor

I think this is not a regression in 6.5, so for me, it doesn't have to land in 6.5 (especially at this stage)

@getdave
Copy link
Contributor

getdave commented Mar 18, 2024

I'm still yet to review the PR in detail but I'd certainly trust your judgement on bug vs regression.

@youknowriad
Copy link
Contributor

I wouldn't mind a confirmation though, it's more of a guess :)

@getdave
Copy link
Contributor

getdave commented Mar 18, 2024

Having reviewed the PR and Issue, it's my understanding that whilst this Issue is important to resolve it is not a regression introduced during the 6.5 RC period (or indeed within the 6.5 release).

The PR author (and/or others) may have a different view on this which I'm sure we'd all be open to hearing.

For now I'll remove the backport label to avoid potential confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Block editor /packages/block-editor [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants