[wp-trac] [WordPress Trac] #29158: Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin
WordPress Trac
noreply at wordpress.org
Mon Oct 3 11:08:12 UTC 2016
#29158: Customizer UI Design lacks contrast for visual hierarchy and does not match
wp-admin
-------------------------------------------------+-------------------------
Reporter: celloexpressions | Owner: helen
Type: enhancement | Status: reviewing
Priority: normal | Milestone: 4.7
Component: Customize | Version: 3.8
Severity: normal | Resolution:
Keywords: color-contrast needs-patch ui- | Focuses: ui,
feedback | accessibility
-------------------------------------------------+-------------------------
Comment (by folletto):
Not sure if commenting here is the right place given a patch has already
been committed in core, however after some testing I think we need to fix
the balance between mouse hover and keyboard focus. Specifically, the two
should be different, and the mouse one shouldn't be so overwhelming as it
is now – a feature that instead is instead very important to keyboard
focus.
I added i9 that suggests an idea to fix this:
1. Mouse focus changes text color to standard blue.
2. Keyboard focus is as-is already committed, no change (change of
background, side margin). If possible I'd make text contrast higher (full
black) so it's even more readable.
3. Notice how switching color on mouse hover and not on keyboard, makes
the mouse hover to still work even when there's keyboard focus (it
combines the keyboard styling with the mouse hover).
4. The close button, IF and only IF we implement the fix above to avoid it
getting selected by default, could get a mirror keyboard marking to the
bottom bar. If I understood correctly the comment
[https://wordpress.slack.com/archives/core-customize/p1474921502001317
here], skipping focus on the close button to the first element of the list
will actually be an improvement.
5. If there are no issues, I'd also suggest to add to all the hover
controls a transition, something like: `transition: all 150ms ease-in;`
(or less ms).
I did some tests live patching and the above seems striking a good
balance to me. Note that the mouse focus might not seem much, but the user
has the cursor already tracking, so it works well.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29158#comment:82>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list