WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 5 weeks ago

Last modified 5 days ago

#47153 closed defect (bug) (fixed)

Field boundaries have insufficient color contrast

Reported by: anevins Owned by: audrasjb
Milestone: 5.3 Priority: normal
Severity: minor Version:
Component: Administration Keywords: needs-post-mortem has-screenshots wpcampus-report color-contrast form-controls has-patch 5-3-admin-css-changes has-dev-note
Focuses: ui, accessibility Cc:
PR Number:

Description (last modified by afercia)

Moved from the WPCampus accessibility report issues on GitHub, see : https://github.com/WordPress/gutenberg/issues/15272

  • Severity:
    • Low
  • Affected Populations:
    • Low-Vision
    • Cognitively Impaired
  • Platform(s):
    • All / Universal
  • Components affected:
    • Edit Media

Issue description
On the Edit Media page, several interactive components have insufficient
color contrast for their borders or backgrounds, below the minimum 3:1
for interface components:

Text input borders: #ddd (light-grey) against #fff (white): 1.35.
Checkbox and radio borders: #b4b9be (light grey) against #fff (white): 1.97.
Focus shadow for fields and buttons: #5b9dd9 (light blue) on #fff (white): 2.88.
Sufficient color contrast is important for users who have low-vision or
are color-blind, because content with a low contrast ratio may be
difficult or impossible for such users to see.

Issue Code

input[type=checkbox], input[type=color], input[type=date], input[type=datetime-local], input[type=datetime], input[type=email], input[type=month], input[type=number], input[type=password], input[type=radio], input[type=search], input[type=tel], input[type=text], input[type=time], input[type=url], input[type=week], select, textarea {
        border: 1px solid #ddd;
        box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
        background-color: #fff;
        ...
    }

    /* radio buttons, checkmarks */
    input[type=checkbox], input[type=radio] {
        border: 1px solid #b4b9be;
        ...
    }

    /* focus state */
input[type=checkbox]:focus, input[type=color]:focus, input[type=date]:focus, input[type=datetime-local]:focus, input[type=datetime]:focus, input[type=email]:focus, input[type=month]:focus, input[type=number]:focus, input[type=password]:focus, input[type=radio]:focus, input[type=search]:focus, input[type=tel]:focus, input[type=text]:focus, input[type=time]:focus, input[type=url]:focus, input[type=week]:focus, select:focus, textarea:focus {
        border-color: #5b9dd9;
        box-shadow: 0 0 2px rgba(30,140,190,.8);
    }

    /* buttons at top */
    .wp-core-ui .button-secondary:focus, .wp-core-ui .button.focus, .wp-core-ui .button:focus {
        box-shadow: 0 0 3px rgba(0,115,170,.8);
    }

    #screen-meta-links .show-settings {
        border: 0;
        ...
    }

Remediation Guidance
Darken the gray borders and the focus shadow color to provide a minimum
contrast ratio of 3:1 relative to the white background.

Since box-shadow is not shown in High Contrast themes, this should
also be supplemented with a transparent outline (or replaced with a
visible outline).

Recommended Code

input[type=checkbox], input[type=color], input[type=date], input[type=datetime-local], input[type=datetime], input[type=email], input[type=month], input[type=number], input[type=password], input[type=radio], input[type=search], input[type=tel], input[type=text], input[type=time], input[type=url], input[type=week], select, textarea {
        border: 1px solid #949494;
        box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
        background-color: #fff;
        ...
    }

    /* radio buttons, checkmarks */
    input[type=checkbox], input[type=radio] {
        border: 1px solid #949494;
        ...
    }

    /* focus state */
input[type=checkbox]:focus, input[type=color]:focus, input[type=date]:focus, input[type=datetime-local]:focus, input[type=datetime]:focus, input[type=email]:focus, input[type=month]:focus, input[type=number]:focus, input[type=password]:focus, input[type=radio]:focus, input[type=search]:focus, input[type=tel]:focus, input[type=text]:focus, input[type=time]:focus, input[type=url]:focus, input[type=week]:focus, select:focus, textarea:focus {
        border-color: #5999d4;
        box-shadow: 0 0 2px rgba(30,140,190,.8);
        outline: 1px solid transparent;
    }

    /* buttons at top */
    #screen-meta-links .show-settings:focus {
        border: 1px solid #0073aa;
        ...
    }

Relevant standards

  • 1.4.11 Non-text Contrast (Level AA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-76 in Tenon's report

Note: Partly covered also in #15275.

Note: The media modals aren't part of Gutenberg. This issue should be moved to the core Trac under the Media component.

Note: There are also a few related core Trac tickets, see:

Attachments (49)

57186393-2b775700-6e93-11e9-9935-c6770c0d7db9.png (258.0 KB) - added by anevins 6 months ago.
57186399-5792d800-6e93-11e9-9d03-dc633d1b5795.png (112.1 KB) - added by anevins 6 months ago.
Screen Shot 2019-06-20 at 2.50.52 PM.png (82.0 KB) - added by melchoyce 5 months ago.
Let's swap all core input styles for Gutenberg input styles.
Capture d’écran 2019-08-17 à 10.12.08.png (277.7 KB) - added by audrasjb 3 months ago.
Add gutenberg styles to media modal forms elements
47153.diff (842 bytes) - added by audrasjb 3 months ago.
Add gutenberg styles to edit media screen forms elements
Capture d’écran 2019-08-17 à 10.35.30.png (82.0 KB) - added by audrasjb 3 months ago.
Also change Classic Editor form elements
Capture d’écran 2019-08-17 à 10.41.42.png (46.7 KB) - added by audrasjb 3 months ago.
Publish metabox as well
Capture d’écran 2019-08-17 à 10.43.20.png (81.2 KB) - added by audrasjb 3 months ago.
47153.diff user edit screen
Capture d’écran 2019-08-17 à 10.43.46.png (97.5 KB) - added by audrasjb 3 months ago.
47153.diff writing settings screen
Capture d’écran 2019-08-17 à 10.44.11.png (75.6 KB) - added by audrasjb 3 months ago.
47153.diff media settings screen
Capture d’écran 2019-08-17 à 10.46.16.png (662.4 KB) - added by audrasjb 3 months ago.
47153.diff themes screen
Capture d’écran 2019-08-17 à 10.46.28.png (180.4 KB) - added by audrasjb 3 months ago.
47153.diff comments screen
Capture d’écran 2019-08-17 à 10.46.41.png (103.8 KB) - added by audrasjb 3 months ago.
47153.diff posts screen
Capture d’écran 2019-08-17 à 10.46.59.png (197.0 KB) - added by audrasjb 3 months ago.
47153.diff dashboard screen
Capture d’écran 2019-08-17 à 10.47.24.png (172.1 KB) - added by audrasjb 3 months ago.
47153.diff plugins screen
47153.2.diff (1.8 KB) - added by audrasjb 3 months ago.
Finally adding changes to screen-meta as well :)
Capture d’écran 2019-08-17 à 11.01.39.png (93.0 KB) - added by audrasjb 3 months ago.
47153.2.diff screen metas
Capture d’écran 2019-08-17 à 11.03.31.png (105.0 KB) - added by audrasjb 3 months ago.
47153.2.diff screen metas deployed
47153.3.diff (1.8 KB) - added by kjellr 3 months ago.
47153.4.diff (2.2 KB) - added by kjellr 8 weeks ago.
47153.5.diff (1.8 KB) - added by afercia 8 weeks ago.
47153.6.diff (2.0 KB) - added by afercia 8 weeks ago.
installation-screen.png (155.2 KB) - added by audrasjb 8 weeks ago.
Missing styles in Install Screen
login-screen.png (34.6 KB) - added by audrasjb 8 weeks ago.
Missing styles in Login Screen
01 win firefox selects.png (65.8 KB) - added by afercia 8 weeks ago.
Select elements on Windows Firefox
02 ie11 selects.png (61.5 KB) - added by afercia 8 weeks ago.
Select elements with Internet Explorer 11
03 ie11 quick edit fields.png (110.1 KB) - added by afercia 8 weeks ago.
Quick edit form with Internet Explorer 11
04 edit comment textarea no focus.png (125.8 KB) - added by afercia 8 weeks ago.
Edit comment textarea: no focus style in all browsers
47153-login-screen.patch (610 bytes) - added by kjellr 8 weeks ago.
47153.7.diff (771 bytes) - added by afercia 7 weeks ago.
Writing Settings.png (88.0 KB) - added by desrosj 7 weeks ago.
Port input field size is not matching
Settings General - Dates.png (55.3 KB) - added by desrosj 7 weeks ago.
Date custom format fields don't have the new changes
Screen Shot 2019-09-26 at 8.46.29 PM.png (55.3 KB) - added by johnjamesjacoby 7 weeks ago.
Classic Editor Publish Time Date drop-down select styling conflict (overlapping SVG carrot)
current trunk.png (98.6 KB) - added by audrasjb 7 weeks ago.
Current trunk (WP 5.3 beta 1)
pending patches applied.png (98.6 KB) - added by audrasjb 7 weeks ago.
Pending patches applied
Screen Shot 2019-09-28 at 11.33.31 AM.png (13.2 KB) - added by garrett-eclipse 7 weeks ago.
minor css issue w/ height discrepancy between the Bulk Actions select and the Apply button, occurs only on mobile.
47153.8.diff (1.6 KB) - added by afercia 7 weeks ago.
FF login zoom text only.png (126.9 KB) - added by afercia 7 weeks ago.
Screen Shot 2019-09-29 at 12.01.39 PM.png (78.4 KB) - added by johnjamesjacoby 7 weeks ago.
Quick Edit Date "Select" too tall (on mobile)
Screen Shot 2019-09-29 at 12.02.30 PM.png (49.1 KB) - added by johnjamesjacoby 7 weeks ago.
Quick Edit "Select" too tall (on desktop, Safari)
Gutenberg Radio Buttons.png (110.1 KB) - added by desrosj 7 weeks ago.
Gutenberg radio buttons off-centered
Category Checkboxes in Gutenberg.png (47.3 KB) - added by desrosj 7 weeks ago.
Gutenberg category checkbox check is not white/not enough contrast
List Table Selects.png (73.5 KB) - added by desrosj 7 weeks ago.
List table select field text not vertically centered (Firefox MacOS)
media library jump.gif (9.4 MB) - added by desrosj 7 weeks ago.
Media library jumps clicking Bulk Select
Screen Shot 2019-09-30 at 2.05.14 PM.png (22.9 KB) - added by garrett-eclipse 7 weeks ago.
Cusomizer > Site Identity has short inputs
customizer-widgets.gif (2.3 MB) - added by desrosj 7 weeks ago.
Customizer widget fields are too short
47366.customizer.lineheight.diff (387 bytes) - added by garrett-eclipse 7 weeks ago.
Patch to address input line-heights in Customizer
Screen Shot 2019-10-01 at 12.51.36 AM.png (40.9 KB) - added by garrett-eclipse 7 weeks ago.
Screen illustrating fix
47153.9.diff (2.1 KB) - added by afercia 7 weeks ago.

Change History (135)

#1 @afercia
6 months ago

  • Component changed from Media to Administration

Basically, this applies to al the input fields in the admin.

#2 @afercia
6 months ago

  • Keywords color-contrast form-controls added

#3 @afercia
6 months ago

  • Milestone changed from Awaiting Review to 5.3

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


5 months ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 months ago

@melchoyce
5 months ago

Let's swap all core input styles for Gutenberg input styles.

#6 @afercia
5 months ago

@melchoyce thanks! Would you say the Gutenberg style should be used also for #47150? (I guess yes and it would make sense to me)

#7 @melchoyce
3 months ago

Yeah, I think we should go with what @kjellr mocked up in that ticket. Thanks for checking 👍

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


3 months ago

#9 @audrasjb
3 months ago

  • Owner set to audrasjb
  • Status changed from new to assigned

Related: #47150

@audrasjb
3 months ago

Add gutenberg styles to media modal forms elements

@audrasjb
3 months ago

Add gutenberg styles to edit media screen forms elements

#10 @audrasjb
3 months ago

  • Keywords has-patch added; needs-patch removed

In 47153.diff I added Gutenberg styles to the edit media screen.

I didn't changed the styles of the help tabs (top right screen elements) since it has to be handled in a global ticket for the whole WP admin interface in my opinion.

#11 @audrasjb
3 months ago

FWIW, 47153.diff also changes the Classic Editor screen (see screenshot below).

@audrasjb
3 months ago

Also change Classic Editor form elements

@audrasjb
3 months ago

Publish metabox as well

@audrasjb
3 months ago

47153.diff user edit screen

@audrasjb
3 months ago

47153.diff writing settings screen

@audrasjb
3 months ago

47153.diff media settings screen

@audrasjb
3 months ago

47153.diff themes screen

@audrasjb
3 months ago

47153.diff comments screen

@audrasjb
3 months ago

47153.diff posts screen

@audrasjb
3 months ago

47153.diff dashboard screen

@audrasjb
3 months ago

47153.diff plugins screen

@audrasjb
3 months ago

Finally adding changes to screen-meta as well :)

#12 @audrasjb
3 months ago

In 47153.2.diff: I finally added these changes to screen meta elements as well :)

Looks great to me. See screenshots below.

@audrasjb
3 months ago

47153.2.diff screen metas

@audrasjb
3 months ago

47153.2.diff screen metas deployed

This ticket was mentioned in Slack in #design by audrasjb. View the logs.


3 months ago

#14 @audrasjb
3 months ago

  • Keywords needs-testing needs-design-feedback added

Adding needs-design-feedback so the patch could get a review from the design team.
See screenshot above.

Adding needs-testing keyword as well, since it's a pretty big modification on the interface and there could be a lot of edgecases.

#15 @afercia
3 months ago

Worth noting while the Gutenberg #8d96a0 color works on a white background, it doesn't on the core grey backgrounds. Typically: #f1f1f1, #f3f3f3, #eeeeee.

For more details, please see ticket:47150#comment:19

This ticket was mentioned in Slack in #core by pento. View the logs.


3 months ago

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


3 months ago

@kjellr
3 months ago

#18 @kjellr
3 months ago

(Whoops... I originally posted this over in #47150. Sorry about that.)


👋 Thanks for the patch and screenshots, @audrasjb. I've updated the patch to include the same color used in #47150 (#7e8993 instead of #8d96a0).

First, a small note: While this adopts the border color from Gutenberg, it doesn't entirely adopt the entire treatment: Focused fields in Gutenberg have a thicker border. I think we should probably tie that into this patch too so that things are consistent:

https://cldup.com/i4XHxpyXzh.png

On, then on to the larger notes:

In general, the interface in WP-Admin is very light and low-contrast. It's made up of lots of light grays. We do need to change the field border color to a darker one, but in an interface as light as this, adding such a dark color creates a visual hierarchy shift in a few areas. Before we move forward, I'd like for us to at least have a plan in mind for balancing that out.

Here's a before and after screenshot of the Categories page for example:

Before
https://cldup.com/XVgt_6YCiR.png

After
https://cldup.com/gNiniheJ6z.png

A couple specific things to point out: In the before screenshot, the table comes forward as the main focal point, while the "Add a new category" sidebar on the left recedes into the background. In the after screenshot, the sidebar is overwhelmingly prominent — it's definitely the first thing that draws the eye. The new dark borders of the "Bulk Actions" dropdown also add a heaviness that outweighs the table.

This new imbalance is especially obvious when focusing in on the relationship between the select components and their action buttons:

Before
https://cldup.com/FHyGDliQLC.png

After
https://cldup.com/AJA3RPWRs3.png

In the before screenshot, the button is (rightly, I'd say) more prominent than the select. That hierarchy is flipped in the new screenshot. (Since Gutenberg uses the same styles that are in this new screenshot, I wonder if this should be udpated there too. 🤔)

---

Anyway, I took a really quick stab at evening out some of these imbalances, to create a hierarchy that's more similar to what we have today:

https://cldup.com/5WgHZIzrSY.png

In this new example, I've:

  • Darkened the borders of our default buttons so that they're more on par with the hierarchy of the form fields.
  • Darkened the checkbox borders to match the form field borders.
  • Darkened the borders and dividers inside of the table on the right, to try returning a bit more visual weight to it.

It's not a fully-thought out solution, but it could be a start. Since this is a substantial change, I'd love to get some other designers to weigh in on all this too.

cc @melchoyce, @jasmussen and @davewhitley — I think you'll all be interested in this discussion.

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


2 months ago

This ticket was mentioned in Slack in #design by kjell. View the logs.


2 months ago

#21 @kjellr
2 months ago

Just a brief update: The design team is discussing this issue along with a couple other relevant tickets here:
https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/

Feel free to weigh in there if anyone else has thoughts. Once we have alignment there, we'll bring any related design changes back into this ticket. 👍

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 months ago

This ticket was mentioned in Slack in #design by kjell. View the logs.


2 months ago

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


8 weeks ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


8 weeks ago

@kjellr
8 weeks ago

#26 @kjellr
8 weeks ago

I just added 47153.4.diff. This adds the double-wide border for the focused state for form fields. It also:

  • Updates the blue color to the one used in Gutenberg.
  • Adds the darker borders to checkboxes + radio buttons. (For now, it does not make these borders 2px like Gutenberg's. That is a more complicated fix, and I think it should be handled alongside tickets like #47498)
  • It updates the meta options / help border to use the colors used in #48101.

Screenshots

https://cldup.com/mJJup3VmLu-3000x3000.png

https://cldup.com/C4Efo7pYEv-1200x1200.png

https://cldup.com/ftYb2RyiR9-3000x3000.png

#27 @kjellr
8 weeks ago

Oh, also! The latest patch also ensures that textboxes have rounded borders. This is great except for one glaring bug: The title field in Gutenberg.

https://cldup.com/4JizANRmpb-3000x3000.png

I'm pretty sure this is the only case where we do not want the field to have rounded corners, so it seems like something that should be fixed in Gutenberg. If this gets merged into core, I suggest we open a ticket there.

Last edited 8 weeks ago by kjellr (previous) (diff)

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


8 weeks ago

@afercia
8 weeks ago

#29 @afercia
8 weeks ago

47153.5.diff refreshes the patch after recent changes.

#30 @afercia
8 weeks ago

47153.6.diff adds a missing semicolon.

@afercia
8 weeks ago

#31 @afercia
8 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 46247:

Accessibility: Improve and modernize user interface controls for better contrast. Fifth part: Common form controls.

Props anevins, melchoyce, audrasjb, kjellr.
Fixes #47153.

#32 @afercia
8 weeks ago

  • Keywords needs-testing needs-design-feedback removed

@audrasjb
8 weeks ago

Missing styles in Install Screen

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


8 weeks ago

@audrasjb
8 weeks ago

Missing styles in Login Screen

#34 @audrasjb
8 weeks ago

@ocean90 found Login and Installation screens are missing new form styles. See screenshots above.

For reference, see related slack discussion: https://wordpress.slack.com/archives/C02RP4X03/p1569271942495500

Will reopen the ticket after WP 5.3 Beta 1 is released.

#35 @afercia
8 weeks ago

Reported by @desrosj on Slack.

On macOS Firefox:

1
The top and bottom of the select elements feels really tight:

http://cldup.com/R6CrA4zwsR.png

2
The text is not centered within the dropdown. This is obvious when focused:

http://cldup.com/qL2RwRbXi0.png

3
In the media library, clicking the Bulk Select button causes a 1px jump of the filter area/page

#36 @afercia
8 weeks ago

Tested a bit also on Windows, spotted a few important things to notice and address (see screenshots below);

  • The Select elements aren't that bad with Windows Firefox: this probably because the different system font metrics and line-height. I'd think also the padding needs adjustments.
  • Internet Explorer 11: the select elements still display the native arrow: this can be targeted with the proprietary ::-ms-expand
  • Internet Explorer 11: in the Quick Edit form some input fields are so narrow that the values can't be read
  • some textarea elements miss a focus style, for example: the Edit Comment textarea

@afercia
8 weeks ago

Select elements on Windows Firefox

@afercia
8 weeks ago

Select elements with Internet Explorer 11

@afercia
8 weeks ago

Quick edit form with Internet Explorer 11

@afercia
8 weeks ago

Edit comment textarea: no focus style in all browsers

#37 @afercia
8 weeks ago

Re: the select elements: looks like min-height doesn't work well with Firefox. It probably needs to use some combination of padding and line-height instead. /Cc @kjellr

Other (proprietary) selectors to target custom browsers UI will need to be used, e.g.:

select:-moz-focusring
select::-ms-value
select::-ms-expand

As a source of inspiration for cross-browser styled selects, see below. Though the implementation is slightly different, some of the CSS rules used in these examples might greatly help:

Scott O'Hara Styled Selects
https://scottaohara.github.io/a11y_styled_form_controls/src/select/
https://github.com/scottaohara/a11y_styled_form_controls/blob/master/src/assets/css/select.css

Yoast styled select
https://github.com/Yoast/wordpress-seo/blob/304116593abb8a06f74b9c8ae20f55ec8c689ba8/css/src/yst_plugin_tools.scss#L773

both inspired by:

Scott Jehl
Styling a Select Like It’s 2019
https://www.filamentgroup.com/lab/select-css.html

#38 @kjellr
8 weeks ago

Attached 47153-login-screen.patch, which is a tiny patch to fix the card border and focus styles on the login screen.

https://cldup.com/8sz1lnRCJi-2000x2000.png

#39 @talldanwp
8 weeks ago

It seems a lot of those issues mentioned with select elements are related to the changes in #47477. I've uploaded a patch there that fixes:

  • Fixes to margin of select elements to ensure text is centered
  • Fixes to quick edit form
  • Removal of native down arrow on select elements in IE

Of the issues mentioned I haven't been able to solve the following, so they're still up for grabs:

  • Edit comment textarea: no focus style in all browsers
  • In the media library, clicking the Bulk Select button causes a 1px jump of the filter area/page
  • The top and bottom of the select elements feels really tight
  • Missing styles in Install Screen

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


7 weeks ago

#41 @audrasjb
7 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to task (blessed)

Reopening this ticket as a blessed task to allow us to iterate on the related changes.

Reopened tickets: #47153, #47477, #47498, #48101

#42 @afercia
7 weeks ago

In 46293:

Accessibility: Implement the new focus styles on the login screen after [46247].

Props @kjellr.
See #47153.

#43 @desrosj
7 weeks ago

Login screen looks good! One thing I am noticing on Firefox for MacOS (and I am also seeing it in the latest screenshot above), the password field is a different height than the username field. This is also causing the eye icon to not be vertically centered.

#44 @kjellr
7 weeks ago

Login screen looks good! One thing I am noticing on Firefox for MacOS (and I am also seeing it in the latest screenshot above), the password field is a different height than the username field. This is also causing the eye icon to not be vertically centered.

You're right. I bet that is related to the min-height changes that came in via #47477.

@afercia
7 weeks ago

#45 @afercia
7 weeks ago

on Firefox for MacOS (and I am also seeing it in the latest screenshot above), the password field is a different height than the username field.

Thanks @desrosj. Yep, old known stuff: Firefox / Chrome use a different default min line-height for input fields.

47153.7.diff addresses this issue by setting an explicit line-height. Worth exploring if all input fields would need a line-height as well.

Also, makes the username and password fields (and toggle button) scale better with text. This can be tested on Firefox: go to View > Zoom > Zoom Text Only, and then use the zoom normally. Some quick testing would be nice :)

This ticket was mentioned in Slack in #design by kjell. View the logs.


7 weeks ago

#47 @azaozz
7 weeks ago

Also note that #42888 and [46256] possibly introduce a regression as all paragraph tags in wp-login.php have been removed or replaced with divs.

May be missing something but why was this necessary? Also don't see that mentioned anywhere?

Last edited 7 weeks ago by azaozz (previous) (diff)

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


7 weeks ago

@desrosj
7 weeks ago

Port input field size is not matching

@desrosj
7 weeks ago

Date custom format fields don't have the new changes

#49 @afercia
7 weeks ago

Port input field size is not matching

@desrosj Unless I'm missing something that's the intended rendering. Some inputs have a small-text CSS class intended to make them... smaller :) They're smaller also on 5.2.3 and all previous versions.

@johnjamesjacoby
7 weeks ago

Classic Editor Publish Time Date drop-down select styling conflict (overlapping SVG carrot)

#50 @johnjamesjacoby
7 weeks ago

I understand all of the reasons why the work being done here is good. I also appreciate greatly the attention to detail that is going into all of this.

But... I don't think the end result is more visually appealing than it was before.

It's rigid, monochromatic, and inconsistently so. Form fields, meta-boxes, and list tables have strong borders, but the primary and secondary navigation have no lines or borders at all. Inner and outer shadows have been removed from some places and not others.

Visually, selects and secondary buttons now look nearly identical. There isn't enough color contrast between their background colors when side-by-side to naturally identify them as unique elements anymore.

The transition that's applied on :focus is distracting, and makes the UI feel sluggish when trying to quickly navigate between multiple form fields. The speed & snappiness is gone.

It mostly seems like all of the global problems Gutenberg has got moved into the rest of WordPress Admin.

So much is being done here, which is great to see, but this is practically a complete styling overhaul, while also feeling incomplete at the same time.

Maybe this should have been a blog post instead... but I also want to raise concerns here, so that they're out in the open asynchronously. I'm sure I'm wrong, but just in case, here it is.

#51 @afercia
7 weeks ago

  • Keywords 5-3-admin-css-changes added

#52 @audrasjb
7 weeks ago

@johnjamesjacoby thanks for your feedback. Worth noting the patch on this ticket should be tested along with other 5-3-admin-css-changes tickets: https://core.trac.wordpress.org/query?keywords=~5-3-admin-css-changes

See screenshot below for a better view of current work :-)

@audrasjb
7 weeks ago

Current trunk (WP 5.3 beta 1)

@audrasjb
7 weeks ago

Pending patches applied

#53 @afercia
7 weeks ago

  • Description modified (diff)

#54 @afercia
7 weeks ago

@johnjamesjacoby hello and thanks for your feedback, much appreciated. One of the goals of having these changes on trunk is to expose them to a larger audience, get feedback, and keep iterating. I'd say the feedback part is working well :)

Process

I'd like to note these changes come from an extended ongoing effort between teams to improve the overall contrast of all the interactive elements in the WordPress admin. Explorations, discussions, and meetings have being going for weeks on Slack.

A post was published on Make Design for public discussion and request for feedback, see :

Discussion: Higher contrast form fields and buttons
https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/

All the related Trac tickets are open "blessed tasks" and now grouped under the keyword JB mentioned above: https://core.trac.wordpress.org/query?keywords=~5-3-admin-css-changes. This also helps to address specific feedback on specific points.

Main goals

Better accessibility

To meet WCAG level AA, all interactive user interface controls must have a minimum 3:1 contrast ratio with the adjacent color. Reference with details on what the "adjacent color" is:

Success Criterion 1.4.11 Non-text Contrast
https://www.w3.org/TR/WCAG21/#non-text-contrast

Understanding Success Criterion 1.4.11: Non-text Contrast
https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

I'd also like to note the need to improve form controls contrast was discussed way before the current release cycle and previously reported on Trac in #35596 and #44606.

Consistency

I'd like to outline that it's undesirable there's no consistency between the Gutenberg styles and the rest of the WordPress admin. Different form controls styles add cognitive load for users, forcing them to "learn" different user interface patterns and controls feedback depending on the page they're using.

Sooner or later, consistency needs to be introduced anyways. On the protracted lack of consistency between Gutenberg and the admin we could open an entirely separate conversation :)

There are different options to introduce the necessary consistency. Personally (for what is worth) I'm not opposed to move the Gutenberg styles to the rest of the admin and then iterate from there. I do know some Gutenberg patterns can be improved. I'd tend to think a good first step is to have only one pattern across all the admin and then explore further improvements.

Specific feedback

On some of your specific points:

Visually, selects and secondary buttons now look nearly identical. There isn't enough color contrast between their background colors when side-by-side to naturally identify them as unique elements anymore.

Right. This is going to change: selects will have a white background and secondary buttons a blue border. See #48128, #34904 and related discussion between teams during last weekly accessibility meeting.

The transition that's applied on :focus is distracting, and makes the UI feel sluggish when trying to quickly navigate between multiple form fields. The speed & snappiness is gone.

Good point. I see now that input fields and selects do have a transition effect. Buttons don't. This is clearly annoying when inputs/selects live close to buttons and receive focus sequentially. I'd recommend to remove the transition for now and re-evaluate later. /Cc @kjellr

At the very least, the transition should obey the prefers-reduced-motion setting. Personally, I'd be in favor or removing the transition entirely, also from Gutenberg.

@garrett-eclipse
7 weeks ago

minor css issue w/ height discrepancy between the Bulk Actions select and the Apply button, occurs only on mobile.

@afercia
7 weeks ago

#55 @afercia
7 weeks ago

47153.8.diff refreshes 47153.7.diff for the login screen to allow the form controls to scale with text zoom. All the relevant units are now expressed in rem. Fixes also the height of the input fields.

Easier way to test: Firefox > View > Zoom > Zoom Text Only, and then zoom in of a few levels. See attached screenshot.

@johnjamesjacoby
7 weeks ago

Quick Edit Date "Select" too tall (on mobile)

@johnjamesjacoby
7 weeks ago

Quick Edit "Select" too tall (on desktop, Safari)

#56 @afercia
7 weeks ago

minor css issue w/ height discrepancy between the Bulk Actions select and the Apply button, occurs only on mobile.

Quick Edit Date "Select" too tall (on mobile)

Quick Edit "Select" too tall (on desktop, Safari)

Thanks :) Seems to me those happen also on 5.2 and all previous versions. Existing inconsistencies between elements: .small-text inputs have a different height, on mobile some form controls and the buttons have different heights, etc. FYI it happens also with input fields and buttons.

We can certainly try to do out best to fix these inconsistencies but they're a bit out of the scope of the contrast and focus improvements. Working on #47477 I noticed several existing issues related to different heights. I'd tend to think this should be addressed in a separate effort, planning well in advance the values for the small / normal / large sizes and how they should behave on mobile. For example, on mobile the small / normal / large button sizes change all to a height of 32 pixels. Makes sort of sense but all the other form controls have different heights... :)

Aside: I'm using https://github.com/helenhousandi/wp-style-guide which helps checking most of the form controls. It's a bit old (throws a notice, doesn't list all the form controls / buttons variations). The more I dive into these CSS changes the more I think it would be great to revive this plugin and use it as tool for any future UI development.

@desrosj
7 weeks ago

Gutenberg radio buttons off-centered

@desrosj
7 weeks ago

Gutenberg category checkbox check is not white/not enough contrast

@desrosj
7 weeks ago

List table select field text not vertically centered (Firefox MacOS)

@desrosj
7 weeks ago

Media library jumps clicking Bulk Select

#57 @desrosj
7 weeks ago

I did some more testing tonight. I am still seeing several bugs. I made sure to verify that these are not happening in 5.2.x before posting.

#58 @talldanwp
7 weeks ago

There have been some fixes in Gutenberg related to a couple of those things, GB17571 fixed the category checkboxes. There was also a fix for the radio buttons, but that seems to still need some work—I'm seeing the same issue as mentioned above currently.

I'll look at fixing that today over on the GB repo.

Last edited 7 weeks ago by talldanwp (previous) (diff)

#59 @talldanwp
7 weeks ago

@garrett-eclipse @johnjamesjacoby @desrosj For select elements you'll need to make sure you have the latest patch from #47477 applied.

Even with that there are still differences between the size of the select elements and regular inputs, which is due to the font-size being different (13px for selects, 14px for inputs).

#60 @afercia
7 weeks ago

There have been some fixes in Gutenberg related to a couple of those things

Thanks! Much appreciated.

Thanks all for reporting your findings! On #47477 some testing of the last patch https://core.trac.wordpress.org/attachment/ticket/47477/47477.7.diff would be greatly appreciated.

Even with that there are still differences between the size of the select elements and regular inputs, which is due to the font-size being different

Yep. As noted in ticket:47477#comment:40 some of those heights differences are pre-existing issue and happen in all previous versions both on large and small screens views.

@garrett-eclipse
7 weeks ago

Cusomizer > Site Identity has short inputs

#61 @garrett-eclipse
7 weeks ago

Testing 5.3 Beta2 I came across the Site Title and Tagline inputs in the Customizer > Site Identity and found they're much shorter than anywhere else in the admin.

@desrosj
7 weeks ago

Customizer widget fields are too short

#62 @desrosj
7 weeks ago

Can confirm, the widget inputs are the proper height in 5.2.3. Same with Screen Shot 2019-09-30 at 2.05.14 PM.png.

#63 follow-up: @afercia
7 weeks ago

Thanks both, good catch!

Quickly checking, the customiser sets its own line-height: 1.3; CSS value for some input fields. It needs to be removed, so that the default line-height is inherited.

One-line change. Patch welcome :)

#64 @afercia
7 weeks ago

Patches (and reports) related to sizes should go on #47477 please :)

@garrett-eclipse
7 weeks ago

Patch to address input line-heights in Customizer

@garrett-eclipse
7 weeks ago

Screen illustrating fix

#65 in reply to: ↑ 63 @garrett-eclipse
7 weeks ago

Replying to afercia:

Thanks both, good catch!

Quickly checking, the customiser sets its own line-height: 1.3; CSS value for some input fields. It needs to be removed, so that the default line-height is inherited.

One-line change. Patch welcome :)

Hi @afercia please see 47366.customizer.lineheight.diff for removal of the afflicting CSS in Customizer.

#66 @afercia
7 weeks ago

Thanks @garrett-eclipse! Will commit referencing #47477 which is the ticket related to sizes.

@afercia
7 weeks ago

#67 @afercia
7 weeks ago

47153.9.diff refreshes 47153.8.diff for the login screen.

  • allows the login input fields to better scale with text
  • improves the input fields layout on Internet Explorer 11
  • uses the new focus style on the "Show password" button
  • adjusts the CSS for the interim login

#68 @afercia
7 weeks ago

In 46371:

Accessibility: Improve and modernize user interface controls for better contrast: Login screen improvements.

  • allows the login input fields to better scale with text
  • improves the input fields layout on Internet Explorer 11
  • uses the new focus style on the "Show password" button
  • adjusts the CSS for the interim login

See #47153.
See #42888.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


6 weeks ago

#70 @afercia
6 weeks ago

In 46425:

Accessibility: Improve and modernize user interface controls: Revert the new links focus style.

Thew new dotted outline for the links focus style introduced in [46241] doesn't appear to be ready to guarantee a good indication of focus.
It was agreed to restore the previous links focus style and postpone exploration for a new style to the next release cycle.
Partially reverts [46241] and [46293].

See #34904, #47153.

#71 @azaozz
5 weeks ago

  • Keywords needs-post-mortem added
  • Type changed from task (blessed) to enhancement

I'm sorry but this doesn't seem to work well. I don't consider myself to be "Cognitively Impaired" but I do have "Low-Vision" and this change makes it harder for me to read text in these fields and also to enter text. Generally typing in small boxes that have very dark boundaries makes it difficult to see well and causes my eyes to strain more than usual.

I'm not sure where this part comes from and how it was tested:

Darken the gray borders and the focus shadow color to provide a minimum contrast ratio of 3:1 relative to the white background.

But for me this has the opposite effect :(

Regarding process: this is a low-priority enhancement, not really a "task". This shouldn't have been committed during beta. Also, this ticket is only for the media modal, why do we suddenly have dark borders on all text fields in wp-admin? How was that tested for usability?

It also seems to make it worse for specific group of users (perhaps with specific medical conditions), while in theory benefiting another group of users. I think more feedback is needed before making such changes, it's not OK to degrade the experience for some users :(

Last edited 5 weeks ago by azaozz (previous) (diff)

#72 follow-up: @afercia
5 weeks ago

  • Type changed from enhancement to defect (bug)

I'm sorry but this doesn't seem to work well. I don't consider myself to be "Cognitively Impaired" but I do have "Low-Vision" and this change makes it harder for me to read text in these fields and also to enter text. Generally typing in small boxes that have very dark boundaries makes it difficult to see well and causes my eyes to strain more than usual.

I'm sorry but I do have low vision as well, I guess a bit more serious than you :) By the way this is not a competition on who of us has the worse eyesight lol. In the current WordPress 5.2 admin I really struggle to see where input fields boundaries are. Regardless, this is a personal feedback as well as yours one is a personal feedback.

I'm not sure where this part comes from and how it was tested:

WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast
https://www.w3.org/TR/WCAG21/#non-text-contrast

Basically: any UI controls must have a contrast ratio of at least 3:1 against adjacent color(s).

I'd like to remind everyone that the WCAG recommendations are not personal opinions. As @joedolson well said recently, there is a reason that we try and conform to the principles in WCAG guidelines; and that is because they're based on research, rather than on personal preference; personal preference is generally not a good criteria to base decision making on.

I'd add that they come from years and years of research and user testing from the most renowned experts on the field. They really don't need ad-hoc user testing: they're standards.

Also, this ticket is only for the media modal, why do we suddenly have dark borders on all text fields in wp-admin?

I'd like to remind this ticket was ported from the GitHub issue created after the WPCampus report on the Gutenberg accessibility. The WPCampus report focused (and was contracted for that) only on Gutenberg. They audited all the screens they were able to reach from the Gutenberg UI including the Edit Media page in this specific case. They were not contracted to audit other parts of WordPress nor they are supposed to know what part of the UI pertains to Gutenberg or to the WordPress legacy admin.

That said, the contrast ratio principle applies to all UI controls. I'm not sure I understand your point. Changing only the contrast of the input fields in the Edit Media page wouldn't make sense because the contrast problem applies to all the admin. See comment:1.

See also #47150 and previously: #44749, #44606, #38150, #35596.

Specifically, #44606 was opened 15 months ago and #35596 4 years ago as bugs.

This ticket being a bug, I'd like to change it back to "bug". Worth noting it was changed to "blessed task" by the accessibility focus lead for this release cycle to allow to iterate and address potential edge cases. See comment:41.

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


5 weeks ago

#74 in reply to: ↑ 72 @azaozz
5 weeks ago

Replying to afercia:

Basically: any UI controls must have a contrast ratio of at least 3:1 against adjacent color(s).

I'd like to remind everyone that the WCAG recommendations are not personal opinions....

This is an unfortunate news to me, personally. So basically WCAG 2.1 can make recommendations that are inappropriate, and possibly harmful, for some groups of users in certain cases...

Reading longer text that is tightly wrapped in dark border is harder for most users, and can be quite hard for people with diminished vision :(

This doesn't seem to apply to buttons or other elements that have short text. In these cases the text is read once or twice, then the user "learns' to recognize the button/element and does not need to re-read it every time. However longer, "changeable" text needs to be read every time.

Can this recommendation be implemented in a way that takes the needs of all users into account?

#75 @afercia
5 weeks ago

Reading longer text that is tightly wrapped in dark border is harder for most users, and can be quite hard for people with diminished vision

This is an interesting point. Do you have any data or research to support it especially for the "for most users" part? In that case, it would be interesting to report upstream to the W3C GitHub and ask for feedback.

#76 @afercia
5 weeks ago

Worth also noting that input fields on Gutenberg already use a gray for the input fields that has a contrast ratio of 3.1 with the background.

On WordPress 5.2 it's border: 1px solid #8d96a0; which against the Gutenberg white background gives a contrast ratio of exactly 3:1 https://jdlsn.com/color/?type=hex&color=8d96a0&color2=ffffff

For WordPress 5.3 there's the need to take into account the admin pages that use a #f1f1f1 gray background thus the input fields border has been darkened a bit to border: 1px solid #7e8993, also on Gutenberg. This gives a contrast ratio of 3.16:1 against a #f1f1f1 background: https://jdlsn.com/color/?type=hex&color=7e8993&color2=f1f1f1

Screenshot: input field on Gutenberg WordPress 5.2 on the left, trunk on the right:

http://cldup.com/albdsYXYDC.png

Screenshot: input field on the WordPress trunk admin pages with gray background:

http://cldup.com/5TFFkywA6k.png

Compared with the borders on WordPress 5.2:

http://cldup.com/dJLBJcI-R1.png

#77 @audrasjb
5 weeks ago

  • Keywords needs-dev-note added
  • Resolution set to fixed
  • Status changed from reopened to closed

Closing this ticket as fixed for milestone 5.3.
Further work should ideally happens in separate tickets, however the discussion can continue here if we want to track all those admin changes in one ticket.

#79 @johnjamesjacoby
4 weeks ago

The new select styling has the default border radius of select elements as 3px instead of 4px. I see it’s gone back and forth, but I’m not sure why 3px was decided on.

All of the border radii styling in WordPress Admin are a bit scattered, between 3px and 6px in my searching, but 3px seems exclusive to bulk actions and filters, with everything else (inputs, buttons, text areas) defaulting to 4px and being adjusted up or down everywhere else.

Recommend to reopen this and/or change the default border radius to 4px for all select elements, and reduce where needed, to match all other matching form field styling.

Last edited 4 weeks ago by johnjamesjacoby (previous) (diff)

#80 @afercia
4 weeks ago

@johnjamesjacoby thanks, noted :) We're maintaining a list of further improvements that we'd like to implement in the next release cycle. As you may know, on #47477 there's a last patch that aimed to address some of the current glitches but it didn't make it for the release. border-radius isn't in that patch but it's on the to-do list. Not sure a 1 pixel difference in the border-radius worth reopening this ticket as it can be best addressed in the next release cycle together with other improvements.

#81 @johnjamesjacoby
4 weeks ago

@afercia I politely disagree. 😁

This specific CSS is completely new for WordPress 5.3. Selects have never had their styling explicitly owned by WordPress (aside from occasional widths and font sizes.)

Because this is brand new, it’s important to get it right, to avoid plugin authors from needing to support 5.3 specific border-radius styling, knowing it’s going to change in 5.4 right away.

For additional context, I created and maintain a plugin titled WP Chosen that specifically adds styling to jQuery Chosen select replacements, and the border radius changes during the 5.3 cycle have already been a bear to wrestle with so far.

Leaving this as-is for 5.3 is leaving known new-code that isn’t correct or intentional to be everyone else’s problem the next time around.

If this were a small change to an existing bunch of styling, I think I may agree with you about iterating on it later. But because this is new, it should be corrected before 5.3 is considered final.

#82 follow-up: @afercia
4 weeks ago

@johnjamesjacoby thanks again. We agree to disagree then 😁A better knowledge of the background for these visual changes would probably help understand.

This 1 pixel difference in the border-radius between selects/buttons vs. input fields comes from Gutenberg. It's now implemented in core after feedback from the design team. As you're an experienced core contributor and you follow core development closely, you may know that I'm not in the design team. I think your concerns would be better addressed asking the design team.

This specific CSS is completely new for WordPress 5.3. S

Nope :) It's in Gutenberg since several months now. Unless you want to consider Gutenberg something that is "not WordPress", stating that this CSS is completely new is not correct.

Personally, I care about consistency across the WordPress admin. I'd like to see the same, consistent, simple, predictable form controls styling everywhere. Then, if borders are rounded, squared, or à pois I honestly don't mind as long as form controls are accessible :)

Honestly, I'm a bit tired to have to defend the design team decisions when no one from the design team is following or even showing any interest. However, once again: please consider these are design changes so please direct your concerns to the design team.

#83 @afercia
4 weeks ago

That said: if it was up to me I would certainly use the same border-radius value for selects, buttons, and input fields. But, again, that's a design decision ¯\_(ツ)_/¯

#84 in reply to: ↑ 82 @johnjamesjacoby
4 weeks ago

Replying to afercia

This 1 pixel difference in the border-radius between selects/buttons vs. input fields comes from Gutenberg. It's now implemented in core after feedback from the design team. As you're an experienced core contributor and you follow core development closely, you may know that I'm not in the design team. I think your concerns would be better addressed asking the design team.

I’ve asked them, and it’s been deferred to this weeks‘ Design Team Meeting in Slack. Since those changes are happening as part of this ticket (and others) I’m voicing them here for lack of a better non-Slack place. 📨

Nope :) It's in Gutenberg since several months now. Unless you want to consider Gutenberg something that is "not WordPress", stating that this CSS is completely new is not correct.

Gutenberg has had its own styling, thus far targeting its own screen(s). Merging that into this is incomplete either way it’s looked at – either this 3px should be 4px, or all the others should be 3px. 🔄

Personally, I care about consistency across the WordPress admin. I'd like to see the same, consistent, simple, predictable form controls styling everywhere. Then, if borders are rounded, squared, or à pois I honestly don't mind as long as form controls are accessible :)

Here we are in total agreement. 😁

Honestly, I'm a bit tired to have to defend the design team decisions when no one from the design team is following or even showing any interest. However, once again: please consider these are design changes so please direct your concerns to the design team.

If there were a more appropriate ticket to leave this feedback on, I would, but that work is being lumped into this work, across 4 other tickets that don’t explicitly discuss this change or decision as is here. The last I saw, it was 4px. Why it reverted back to 3px has no mention.

If no one wants to own the problem, I will, but the reasonable thing to do is have whomever currently has been making these decisions to chime in before this bug is shipped in 5.3.

#85 @afercia
4 weeks ago

Why it reverted back to 3px has no mention.

FYI: the select elements changes, including the 3 pixels border radius, were discussed on #47477 starting from September 3 see ticket:47477#comment:11 and following comments.

All the proposed visual changes were then published on Make design for public discussion on September 6, including the changes for the select elements, see https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/

Personally, I care about consistency ...

Here we are in total agreement. 😁

Glad to hear that 😁 I'm confident WordPress will get there. There's just the need to remove all the exceptions across the various stylesheets first 🙀

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


5 days ago

Note: See TracTickets for help on using tickets.