Make WordPress Core

Opened 4 years ago

Last modified 7 weeks ago

#49714 assigned enhancement

Explore UI for destructive controls & contexts

Reported by: joedolson's profile joedolson Owned by: travel_girl's profile Travel_girl
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-patch needs-screenshots reporter-feedback
Focuses: ui, accessibility Cc:

Description

After considering ticket #49603, we think that WordPress should take a look at the consistency of informing users when they are in a destructive context and when a control will have destructive consequences.

In general, we have a standing expectation that these controls will be red & have text that clearly indicates the action to be taken, but this should be reviewed for consistency.

Reviewing #49603 showed that the 'Force Erase Personal Data' control is blue, which doesn't match expectations.

The intention of 49603 is to draw attention to the fact that the 'Erase Personal Data' screen is entirely dedicated to destructive actions. While using a background color to indicate this may not be the ideal choice, the concept is well worth exploring.

Summary: review destructive actions & contexts to ensure clarity and maximize error prevention.

Attachments (1)

misleading-focus-outline.png (21.1 KB) - added by azaozz 4 years ago.

Download all attachments as: .zip

Change History (20)

#1 @SergeyBiryukov
4 years ago

Related: #36882.

Tangentially related: #11304, #27370, #28235, #37016, #39712.

#2 @azaozz
4 years ago

In general, we have a standing expectation that these controls will be red & have text that clearly indicates the action to be taken, but this should be reviewed for consistency.

Right, this is the standard expectation (afaik).

Unfortunately there are other inconsistencies with this. One was introduced during the 5.3-beta ill-fated CSS enhancements. When the "Midnight" admin color scheme is selected, all form elements get a heavy red border when in focus. See the above screenshot. This is very confusing as red borders are also used to indicate dangerous/destructive actions.

Looking at it more, there are numerous other inconsistencies/regressions that were introduced in 5.3-beta when using one of the optional admin color schemes (was kind of hoping that the people that introduced them will also fix them but that doesn't seem to be the case). Will open tickets for them.

#3 @azaozz
4 years ago

  • Keywords needs-patch added
  • Milestone changed from Future Release to 5.5

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 years ago

#5 @afercia
4 years ago

This ticket was discussed during today's accessibility bug-scrub.

was kind of hoping that the people that introduced them will also fix them but that doesn't seem to be the case

@azaozz The changes to the alternate color scheme were implemented after feedback from the design team. I'd suggest you to ask the Design team for a new design :) Once we have a design, we can implement it.

Also noting this ticket is specifically about user interface control for destructive actions across the admin, which is a long-standing issue that exists since way before WP 5.3. Lastly, there is a ticket to iterate on the alternate color schemes, see #49999

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 years ago

#8 @afercia
4 years ago

  • Milestone changed from 5.5 to Future Release

This ticket was discussed during today's accessibility bug-scrub: agreed to move it to Future release, as this issue requires a good amount of exploration as a first step.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


8 months ago

#10 @joedolson
8 months ago

  • Keywords needs-screenshots added
  • Milestone changed from Future Release to 6.4
  • Owner changed from joedolson to Travel_girl

#11 @Travel_girl
8 months ago

I have started a Github Repro, as I find it is the best way, to document in an transparent and accessible way.

The Repro is: https://github.com/00travelgirl00/-Explore-UI-for-destructive-controls-contexts-

@joedolson could you please give me some feedback, if the information in the docs are okay and if I should continue or change somehing? At the moment I have followed information included:

Menu-Item / Post
Where: /wp-admin/edit.php?post-action=trash

Behavior:

Default: color: #b32d2e; border: none;
:hover color: #b32d2e; border: none;
:focus color: #b32d2e; box-shadow: 0 0 0 1px #4f94d4,0 0 2px 1px rgba(79,148,212,.8); outline: 1px solid transparent;
additional warning: no

Details:

Link-Text / Button Text: Trash
css-class: a class="submitdelete"
Aria-Label: aria-label="Move “TablePress Test” to the Trash"

Screenshot / Video:

I'm thinking about also providing informations on contrast ratio. But that would also mean much more work.

Also is the css-code a good way for the documentation? I find it more specific and it is easier to catch. But maybe its harder to read?

What do you think? Thanks in advanced

#12 @Travel_girl
8 months ago

The Link is not working to the Github Repro. Here is the correct Link: https://github.com/00travelgirl00/Explore-UI-for-destructive-controls-contexts

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


8 months ago

#14 @oglekler
7 months ago

  • Keywords reporter-feedback added

@joedolson what is the next step? I think #36882 can be handled, please consider milestone it to 6.4.

#15 @joedolson
7 months ago

@oglekler Still looking to see what the scope of issues is. We can add a class, but it would be nice to have a good sense of where it needs to be used first. Mostly we need to know where these classes should be used and how they're currently designed.

These two tickets are pretty closely related, though, certainly.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


7 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


6 months ago

#18 @joedolson
6 months ago

  • Milestone changed from 6.4 to Future Release

#19 @afercia
7 weeks ago

Noting that I just created a similar GitHub issue for the WordPress editor. See https://github.com/WordPress/gutenberg/issues/58390

Note: See TracTickets for help on using tickets.