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

Command centre button: missing focus style and incorrect labeling #51460

Open
afercia opened this issue Jun 13, 2023 · 5 comments
Open

Command centre button: missing focus style and incorrect labeling #51460

afercia opened this issue Jun 13, 2023 · 5 comments
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Package] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Jun 13, 2023

Description

In the Site Editor, the button that opens the 'command centre' has a couple accessibility issues:

  • It misses s focus style.
  • The labelling doesn't tell anything about the button action. Actually, the button opens the command centre modal dialog. There's no text / aria-label or other labelling to communicate what this button does, not even visually. The actual labelling is determined by the button's content, which is, for example: Editing template: Home ⌘K. This labeling is less than ideal because it communicates the current state of the UI instead of the button's action. Instead, any interactive control must communicate what it does. The state should be communicated separately.

Minor:
This whole chunk of HTML is invalid HTML:

  • A button element can't contain div elements.
  • A button element can't contain headings h1, h2, etc.
  • Worth reminding that also span elements can't contain headings h1, h2, etc.

Screenshot: this is how the accessible name of this button is announced by screen readers:

Screenshot 2023-06-13 at 15 19 00

Also worth noting that the visible text and the actual accessible name mismatch: this makes impossible to speech recognition software users issuing a vocal command. See WCAG 2.5.3 Label in Name. the best practice is to make sure that the actual accessible name matches, or at least starts, with the text that is visible to users.

Step-by-step reproduction instructions

  • Go to the Site editor.
  • Use the Tab key to navigate the controls in the top bar.
  • Observ ethe button that opens the command centre doesn't have any focus style.
  • Use a screen reader or just inspect the source to check what the accessible name of the button is.
  • Observe the accessible name is, for example: Editing template: Home ⌘K.
  • Observe the button name doesn't tell anything about the button action.
  • Observe that also visually there's nothing to communicate this button will open the command centre. I don;'t think the visible ⌘K is a clear indication of what this button does.

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 [a11y] Keyboard & Focus [Package] Edit Site /packages/edit-site labels Jun 13, 2023
@afercia
Copy link
Contributor Author

afercia commented Jun 13, 2023

Note that this issue is in part connected with the existing issue about the main H1 in the Site editor and about what the H1 should communicate to users. To start with, seems to me placing the main H1 within this button is very far from ideal, as the button and the H1 should have very different purposes.

@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2023

Additionally, go to:

  • Appearanve > Editor > Pages > Select any page > Click the preview iframe
  • At the bottom of the Settings panel, click 'Edit template'
  • The editor switches to editing template mode
  • The top bar shows an additional 'Back' button before the Command centre button
  • Observe the focus style of the Back button is broken: it is visible only on the right edge of the button
Screenshot 2023-06-28 at 10 02 37

@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2023

Additionally: when hovering one of the two buttons, the hover style changes also on the other button.
I'm not sure this is a great idea, as it hints to user the whole thing is just one control, while they're actually two separate controls. Screenshot with default state and hover state:

Screenshot 2023-06-28 at 10 05 19

Noting this happens also in the Post editor.

I'm not sure I understand the reasoning behind making separate controls look like a single control in the first place. These are separate buttons and should visually appear as separate controls in the first place.

@afercia afercia added the Needs Design Feedback Needs general design feedback. label Jun 28, 2023
@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2023

Additionally:

In the Post editor > Editing template mode, the buttons are separated with some spacing:

Screenshot 2023-06-28 at 11 38 49

In the Site editor instead, the 'Bacl' button is placed 'on top' of the other button. In the screenshot below, I shifted the Back button down a bit to illustrate it sits on top of the other button:

Screenshot 2023-06-28 at 10 49 46

This isn't ideal because, when restoring the focus style to be visible, focusing the Command centre button will draw an outline that ecompasses also the Back button, which would be an incorrect focus indication:

Screenshot 2023-06-28 at 10 50 18

Seems to me the whole CSS grid implementation should be removed and these buttons in the Site editor should use the same CSS flex styling of the buttons in the Post editor. The 'slide in' CSS animation would work in a slightly different manner but it would still work.

@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2023

Assitionally:
On small screens, the Post editor top bar layout breaks at various breakpoints:

post editor

The Site editor behaves a bit better, but still has problems at the smallest viewport sizes:

site editor

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] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

2 participants