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

Improve consistency of the Cancel/OK button pairs #50518

Open
afercia opened this issue May 10, 2023 · 7 comments
Open

Improve consistency of the Cancel/OK button pairs #50518

afercia opened this issue May 10, 2023 · 7 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.

Comments

@afercia
Copy link
Contributor

afercia commented May 10, 2023

Description

In various parts of the UI, Cancel/OK button pairs are in use where the 'OK' button is the primary action (Save, Apply, Create, etc.). These button paris are mostly used within modal dialogs and popups. Turns out there's some inconsistency especially about the 'Cancel' button type / variant: sometimes it's a secondary button, sometimes a tertiary one. There's no apparent reason for this difference. Also, sometimes the alignment and spacing is not consistent.

  • For better consistency, the 'Cancel' buttons should always be either secondary or tertiary.
  • The alignment / spacing should be standardized.

Maybe consider to create a new UI component to ensure consistency and avoid repetitive code.

A few example screenshots:

Secondary:

secondary create template part

Tertiary:

tertiary create reusable block

Tertiary:

tertiary lock block

Tertiary:

tertiary external image

No type specified and inconsistent alignment. This will be likely fixed in #50384

no class classic block

Tertiary:

tertiary navigation ad link popup

Secondary:

secondary delete menu

Tertiary:

tertiary convert to inks

Tertiary:

tertiary create custom template

Tertiary:

tertiary rename tp

Tertiary:

tertiary confirm

Edge cases:

Edit site > VIew mode > Save modal dialog:

edit site view mode save

Guide modal dialog: Previous, Next, and Finish buttons:

Screenshot 2023-05-10 at 14 20 27

Note about the tertiary button accessibility:

Worth reminding the tertiary button isn't fully accessible as it relies only on color. In absence of color, this button is not distinguishable from normal text as there's no shape to identify the button or any other styling to do that (for example an underline).

Step-by-step reproduction instructions

  • Go through the UI and check the styling of the buttons in the screenshots above.

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 [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. labels May 10, 2023
@afercia
Copy link
Contributor Author

afercia commented May 10, 2023

Note: as I'm noticing more and more small inconsistencies in the UI, I'd like to propose to create a new dedicated GitHub issue label for that. Suggestions welcome.

@Mamaduka
Copy link
Member

cc @WordPress/gutenberg-design

@paaljoachim
Copy link
Contributor

I believe @richtabor would like to take a closer look at this issue.

@richtabor
Copy link
Member

I'd like to propose to create a new dedicated GitHub issue label for that.

I don't personally think we need an issue for inconsistencies, but certainly tagging @wordpress/gutenberg-design will help keep them surfaced.

@richtabor
Copy link
Member

richtabor commented May 10, 2023

Very nice.

Buttons

Bringing more consistency is what buttons are used for cancel/ok pairs would be the first step. Looks like some are using secondary, while other tertiary button styles.

Labels

I don't think the labels themselves need to be 1:1 across the board.

They should probably reference the action intended, as these are confirmations. I.e. "Delete Menu" confirmation modal of "Delete Menu", or simply "Delete", not "Confirm". Let's get clear on this before pushing PRs.

The cancel action should always be "Cancel", which looks the be the case (just varying button styles).

@joedolson
Copy link
Contributor

For accessibility, I'd strongly prefer that these actions always used the secondary style. It's a better user experience to be able to recognize controls and know their control boundaries.

@afercia
Copy link
Contributor Author

afercia commented May 22, 2023

For accessibility, I'd strongly prefer that these actions always used the secondary style. It's a better user experience to be able to recognize controls and know their control boundaries.

For reference: the lack of accessibility of the tertiary buttons is a long standing issue and it was reported long time ago in #23890

@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Jul 20, 2023
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. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants