Field boundaries have insufficient color contrast

[anevins]

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:

• #44749
• #44606
• #38150
• #35596

[afercia]

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

[melchoyce]

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

[afercia]

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

[melchoyce]

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

[audrasjb]

Related: #47150

[audrasjb]

Add gutenberg styles to media modal forms elements

[audrasjb]

Add gutenberg styles to edit media screen forms elements

[audrasjb]

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.

[audrasjb]

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

[audrasjb]

Also change Classic Editor form elements

[audrasjb]

Publish metabox as well

[audrasjb]

47153.diff user edit screen

[audrasjb]

47153.diff writing settings screen

[audrasjb]

47153.diff media settings screen

[audrasjb]

47153.diff themes screen

[audrasjb]

47153.diff comments screen

[audrasjb]

47153.diff posts screen

[audrasjb]

47153.diff dashboard screen

[audrasjb]

47153.diff plugins screen

[audrasjb]

Finally adding changes to screen-meta as well :)

[audrasjb]

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

Looks great to me. See screenshots below.

[audrasjb]

47153.2.diff screen metas

[audrasjb]

47153.2.diff screen metas deployed

[audrasjb]

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.

[afercia]

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

[kjellr]

(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:

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

After

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

After

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:

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.

[kjellr]

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. 👍

[kjellr]

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

[kjellr]

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.

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.

[afercia]

47153.5.diff​ refreshes the patch after recent changes.

[afercia]

47153.6.diff​ adds a missing semicolon.

[afercia]

In 46247:

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

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

[audrasjb]

Missing styles in Install Screen

[audrasjb]

Missing styles in Login Screen

[audrasjb]

@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.

[afercia]

Reported by @desrosj ​on Slack.

On macOS Firefox:

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

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

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

[afercia]

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]

Select elements on Windows Firefox

[afercia]

Select elements with Internet Explorer 11

[afercia]

Quick edit form with Internet Explorer 11

[afercia]

Edit comment textarea: no focus style in all browsers

[afercia]

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

[kjellr]

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

[talldanwp]

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

[audrasjb]

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

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

[afercia]

In 46293:

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

Props @kjellr.
See #47153.

[desrosj]

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.

[kjellr]

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]

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 :)

[azaozz]

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?

[desrosj]

Port input field size is not matching

[desrosj]

Date custom format fields don't have the new changes

[afercia]

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]

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

[johnjamesjacoby]

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.

[audrasjb]

@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]

Current trunk (WP 5.3 beta 1)

[audrasjb]

Pending patches applied

[afercia]

@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]

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

[afercia]

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]

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

[johnjamesjacoby]

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

[afercia]

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]

Gutenberg radio buttons off-centered

[desrosj]

Gutenberg category checkbox check is not white/not enough contrast

[desrosj]

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

[desrosj]

Media library jumps clicking Bulk Select

[desrosj]

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.

[talldanwp]

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.

[talldanwp]

@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).

[afercia]

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]

Cusomizer > Site Identity has short inputs

[garrett-eclipse]

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]

Customizer widget fields are too short

[desrosj]

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​.

[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 :)

[afercia]

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

[garrett-eclipse]

Patch to address input line-heights in Customizer

[garrett-eclipse]

Screen illustrating fix

[garrett-eclipse]

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.

[afercia]

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

[afercia]

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

[afercia]

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.

[afercia]

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.

[azaozz]

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.

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 :(

[afercia]

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.

[azaozz]

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?

[afercia]

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.

[afercia]

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:

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

Compared with the borders on WordPress 5.2:

[audrasjb]

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.

[desrosj]

Dev note: ​https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

[johnjamesjacoby]

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.

[afercia]

@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.

[johnjamesjacoby]

@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.

[afercia]

@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.

[afercia]

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 ¯\_(ツ)_/¯

[johnjamesjacoby]

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.

[afercia]

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 🙀

[SergeyBiryukov]

#44749 was marked as a duplicate.

[SergeyBiryukov]

#44606 was marked as a duplicate.