WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 3 years ago

#8730 closed enhancement (wontfix)

Inadequate Contrast in Admin Form Fields

Reported by: miqrogroove Owned by:
Milestone: Priority: normal
Severity: minor Version: 2.7
Component: Accessibility Keywords: has-patch
Focuses: Cc:

Description

An author on my site has advised me that the form fields in wp-admin became practically invisible after upgrading to WP 2.7.

Our solution was to modify this part of wp-admin/css/colors-fresh.css

.form-table input,
.form-table textarea,
.search-input,
.form-field input,
.form-field textarea,
.submit {
	border-color: #DFDFDF;
}

replacing the value with

	border-color: #BBB;

Please consider that the existing value of #DFDFDF creates a light-gray on lighter-gray on white color scheme for text boxes that may contribute to contrast blindness.

Attachments (11)

wp-admin_css_colors-fresh.css.patch (311 bytes) - added by miqrogroove 7 years ago.
Patch version of proposed fix for wp-admin form field contrast.
admin-contrast-css.patch (308 bytes) - added by Cygal 6 years ago.
Updated patch. Works as of r11373, 05/17/09
dfdfdf.png (10.4 KB) - added by Denis-de-Bernardy 6 years ago.
bbb.png (13.7 KB) - added by Denis-de-Bernardy 6 years ago.
8730.diff (626 bytes) - added by Denis-de-Bernardy 6 years ago.
colors-fresh.dev.css.patch (555 bytes) - added by miqrogroove 6 years ago.
Previous patches were broken by version 2.8. Updated to rev 12194
ticket-8730-low-contrast-simulation.gif (10.9 KB) - added by miqrogroove 6 years ago.
This shows what pre-patch WordPress looks like with bad monitor contrast or eyesight problems.
ticket-8730-low-contrast-simulation-patched.gif (9.1 KB) - added by miqrogroove 6 years ago.
Patched website, same browser and settings.
ticket-8730-before.gif (8.8 KB) - added by miqrogroove 6 years ago.
Pre-patch dashboard screenshot.
ticket-8730-after.gif (8.8 KB) - added by miqrogroove 6 years ago.
Patched dashboard screenshot.
admin-contrast.zip (14.0 KB) - added by miqrogroove 6 years ago.
Modular solution helps webmasters avoid patching minor versions.

Download all attachments as: .zip

Change History (41)

@miqrogroove7 years ago

Patch version of proposed fix for wp-admin form field contrast.

comment:1 @miqrogroove7 years ago

  • Keywords has-patch added

comment:2 @ryan7 years ago

  • Component changed from General to UI
  • Owner anonymous deleted

comment:3 @ryan7 years ago

  • Milestone changed from 2.7.1 to 2.8

comment:4 @Denis-de-Bernardy6 years ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 2.8 to 2.9

problems seems to still be around but patch needs to be refreshed

comment:5 @ryan6 years ago

  • Component changed from UI to Accessibility

@Cygal6 years ago

Updated patch. Works as of r11373, 05/17/09

@Denis-de-Bernardy6 years ago

@Denis-de-Bernardy6 years ago

@Denis-de-Bernardy6 years ago

comment:6 @Denis-de-Bernardy6 years ago

Attached two screenshots and an incomplete patch. Jane's opinion would be handy.

@miqrogroove6 years ago

Previous patches were broken by version 2.8. Updated to rev 12194

comment:7 @miqrogroove6 years ago

  • Keywords has-patch added; needs-patch removed

@miqrogroove6 years ago

This shows what pre-patch WordPress looks like with bad monitor contrast or eyesight problems.

@miqrogroove6 years ago

Patched website, same browser and settings.

comment:8 follow-ups: @janeforshort6 years ago

  • Type changed from defect (bug) to enhancement

Can someone screenshot what the patch looks like on a normal contrast monitor and browser combo? We're going to be working on a higher contrast admin theme for people with accessibility needs, so whether or not this patch goes in will depend on how it looks on regular monitors.

@miqrogroove6 years ago

Pre-patch dashboard screenshot.

@miqrogroove6 years ago

Patched dashboard screenshot.

comment:9 in reply to: ↑ 8 @miqrogroove6 years ago

Replying to janeforshort:

We're going to be working on a higher contrast admin theme for people with accessibility needs, so whether or not this patch goes in will depend on how it looks on regular monitors.

As you can see from the new screenshots as well as the old ones, this is neither intended to provide high contrast nor an enhancement of any kind. This is a patch to fix the invisibility of admin inputs on screens with low whitepoint, caused by the version 2.7 CSS changes.

comment:10 @janeforshort6 years ago

  • Milestone changed from 2.9 to Future Release

comment:11 @miqrogroove6 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

I wont even pretend to care about Future Releases. Forget I brought it up.

comment:12 @Denis-de-Bernardy6 years ago

@Jane: I don't mean to be corrosive or anything, but you've a typical example of the WP workflow in this ticket.

Opened, patch added, ticket gets punted without feedback, patch becomes stale, patch gets refreshed, patch becomes stale again, patch gets refreshed again, ticket gets punted yet again without feedback to the St Glinglin, and ticket ends up closed.

comment:13 follow-up: @dd326 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Janes comments seem ok to me. What is the impact of the change on a normal-user with good eyesight/contrast?

The ticket has been punted for a reason, Its an enhancement, with untested/incomplete testing or examples, and close to a release. Contrast issues within the admin are a known problem, the entire admin may need adjustments to deal with that and at present a new theme has been suggested as the solution - as changes made to help some users will be disadvantageous to others.

Its common for tickets to get lost amongst the 1000+ tickets open for any given milestone during the development period where core developers have time to test out these things for themselves, Its not too much to ask for a contributor to provide extra details to help out, Nor is it to hard to remind a dev (by commenting on the ticket) that the issue still exists and needs to be committed (or tested) - Earlier in the dev period, if someone else brought it up this probably would've been tested and committed, but as it is, its fallen through a crack (as many tickets do) due to there being "simpler" tickets ready to be worked on.

I'm re-opening as the issue still exists, But its a minor Accessibility issue which doesnt affect the majority of users, I wouldnt expect it in a release once you hit beta, simply because, as designers/ui testers(Jane) know, changing contrast in things can have wild effects on other screens.

comment:14 in reply to: ↑ 13 @Denis-de-Bernardy6 years ago

Replying to dd32:

Its common for tickets to get lost amongst the 1000+ tickets open for any given milestone during the development period

Indeed it is. Wouldn't it be great if that list got trimmed to a more manageable level at some point? Like under 100?

comment:15 follow-up: @dd326 years ago

Indeed it is. Wouldn't it be great if that list got trimmed to a more manageable level at some point? Like under 100?

New issues are being reported every day, Faster than anyone can code for them all.

Please take all non-ticket discussion to a forum such as wp-hackers which is designed for such issues.

comment:16 follow-up: @janeforshort6 years ago

Thanks, DD32, for saying exactly the correct thing regarding my actions. We're in beta, so tickets that are of lower priority, not sufficiently tested, etc. are all being punted unless they are regressions or actually break things. If more people had brought more traction to this ticket in the last five months, as opposed to it being two people commenting back and forth to each other, it might have gotten bumped up the priority list. If you want a ticket to get traction, get more people to advocate for it. Period.

comment:17 in reply to: ↑ 16 @Denis-de-Bernardy6 years ago

Replying to janeforshort:

If more people had brought more traction to this ticket in the last five months, as opposed to it being two people commenting back and forth to each other, it might have gotten bumped up the priority list. If you want a ticket to get traction, get more people to advocate for it. Period.

Pardon, but rubbish.

If you want more people on tickets and testing tickets, staff the project (i.e. increase the number of committers) in such a way that things get reviewed/committed by actual core devs in short enough time that potential contributors keep interested in staying around and getting things done.

I'm sorry to say, but in the past 8 months or so since I vocally brought this up, and as much as the efforts on this front have been most welcome, things have not gotten much better.

When you've a bug reporter and patch contributor who close a ticket telling you that "I wont even pretend to care about Future Releases. Forget I brought it up.", start to seriously ask yourselves questions. Because it really means nothing short of "get lost, you lost me!".

comment:18 @willmot6 years ago

  • Cc willmot added

comment:19 in reply to: ↑ 15 @hakre6 years ago

Replying to dd32:

New issues are being reported every day, Faster than anyone can code for them all.

Thanks, DD32, for sharing your thoughts. It's exactly the correct thing regarding the overall situation with WordPress development we are currently facing.

The current state is that we are constantly getting more bugs per week than we are able to fix. That simple it is. Until we do not get feature frozen and development concentrates on the root of where all these bugs come from, the project will continue to eat itself. On a commercial project we would have all red lamps on already.

This is nothing that can be controlled by version-number-juggling or punting tickets btw.

comment:20 follow-up: @miqrogroove6 years ago

If I ever saw patches getting punted during a beta cycle under my supervision, heads would be rolling. I've been holding back most of my bug reports because I can't even get the TinyMCE core dependencies fixed. WTF R U DOIN rejecting bugs on a feature-frozen beta cycle for a major version? This is the part where you're supposed to make the software not suck.

comment:21 in reply to: ↑ 20 @Denis-de-Bernardy6 years ago

Replying to miqrogroove:

WTF R U DOIN rejecting bugs on a feature-frozen beta cycle for a major version? This is the part where you're supposed to make the software not suck.

+10000000000000 to that

comment:22 in reply to: ↑ 8 ; follow-up: @lloydbudd6 years ago

  • Milestone changed from Future Release to 3.0

dd32 & janeforshort are right.

The 1st gate for fixing a bug (particularly during beta) is the severity of the issue.

I have not been able to find any customer complaints for this on WordPress.com -- doesn't mean they don't exist, but likely does mean it is rare.

Does seem like a "fix" with no downsides -- setting milestone to 3.0, and assigning to Jane (as seems still waiting on feedback from her ;-)

comment:23 in reply to: ↑ 22 @miqrogroove6 years ago

Replying to lloydbudd:

Does seem like a "fix" with no downsides -- setting milestone to 3.0

Fixes with no downsides belong in version 2.9. What you are doing here is complete nonsense.

comment:24 follow-ups: @azaozz6 years ago

Don't understand the heated discussion and the offensive language. All text field borders across WordPress are the same color. This is a visual design decision and being such makes it subjective. So there would be people that love it, people that don't care and people that hate it.

If there are users with improperly set monitors that cannot see the difference they could switch to the Classic color theme or even use a custom color theme that would work around the deficiencies in their computer setup.

It seems this doesn't fall under the 80%/20% rule, not even 99%/1%. Judging by the feedback it's more like 99.999%/0.001%. So why is this "fix" pushed to the great majority of users that don't need it or may hate it in favor of 0.001% of users that can't be bothered to set their monitors right?

comment:25 in reply to: ↑ 24 @miqrogroove6 years ago

Replying to azaozz:

Don't understand the heated discussion

That's why I closed the ticket. Nothing useful is happening here.

comment:26 @lloydbudd6 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:27 @lloydbudd6 years ago

  • Milestone 3.0 deleted

comment:28 in reply to: ↑ 24 @hakre6 years ago

Replying to azaozz:

So why is this "fix" pushed to the great majority of users that don't need it or may hate it in favor of 0.001% of users that can't be bothered to set their monitors right?

Well I won't stress low-contrast that much really, but actually, there were bigger problems that have been solved now, at least for now.

Keep in mind that in opera it's only a checkbox to deactivate styling of input-elements. That helps a lot for unuseable, subjective design decisions.

Related: #10881

comment:29 @miqrogroove6 years ago

Attached work based on yesterday's conversation with Matt. It's barebone, solves the problem for affected branches, and leaves the core files alone.

@miqrogroove6 years ago

Modular solution helps webmasters avoid patching minor versions.

comment:30 @miqrogroove3 years ago

For future reference, this patch has been refreshed again and moved to http://wordpress.org/extend/plugins/fix-admin-contrast/

Note: See TracTickets for help on using tickets.