#8730 closed enhancement (wontfix)
Inadequate Contrast in Admin Form Fields
Reported by: |
|
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)
Change History (41)
#4
@
16 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
@
15 years ago
This shows what pre-patch WordPress looks like with bad monitor contrast or eyesight problems.
#8
follow-ups:
↓ 9
↓ 22
@
15 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.
#9
in reply to:
↑ 8
@
15 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.
#11
@
15 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.
#12
@
15 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.
#13
follow-up:
↓ 14
@
15 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.
#14
in reply to:
↑ 13
@
15 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?
#15
follow-up:
↓ 19
@
15 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.
#16
follow-up:
↓ 17
@
15 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.
#17
in reply to:
↑ 16
@
15 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!".
#19
in reply to:
↑ 15
@
15 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.
#20
follow-up:
↓ 21
@
15 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.
#21
in reply to:
↑ 20
@
15 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
#22
in reply to:
↑ 8
;
follow-up:
↓ 23
@
15 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 ;-)
#23
in reply to:
↑ 22
@
15 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.
#24
follow-ups:
↓ 25
↓ 28
@
15 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?
#25
in reply to:
↑ 24
@
15 years ago
Replying to azaozz:
Don't understand the heated discussion
That's why I closed the ticket. Nothing useful is happening here.
#28
in reply to:
↑ 24
@
15 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
#29
@
15 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.
#30
@
13 years ago
For future reference, this patch has been refreshed again and moved to http://wordpress.org/extend/plugins/fix-admin-contrast/
Patch version of proposed fix for wp-admin form field contrast.