Inadequate Contrast in Admin Form Fields

[miqrogroove]

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.

[miqrogroove]

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

[Denis-de-Bernardy]

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

[Cygal]

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

[Denis-de-Bernardy]

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

[miqrogroove]

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

[miqrogroove]

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

[miqrogroove]

Patched website, same browser and settings.

[janeforshort]

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.

[miqrogroove]

Pre-patch dashboard screenshot.

[miqrogroove]

Patched dashboard screenshot.

[miqrogroove]

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.

[miqrogroove]

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

[Denis-de-Bernardy]

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

[dd32]

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.

[Denis-de-Bernardy]

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?

[dd32]

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.

[janeforshort]

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.

[Denis-de-Bernardy]

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!".

[hakre]

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.

[miqrogroove]

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.

[Denis-de-Bernardy]

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

[lloydbudd]

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

[miqrogroove]

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.

[azaozz]

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?

[miqrogroove]

Replying to azaozz:

Don't understand the heated discussion

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

[hakre]

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

[miqrogroove]

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

[miqrogroove]

Modular solution helps webmasters avoid patching minor versions.

[miqrogroove]

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