Make WordPress Core

Opened 10 years ago

Closed 7 years ago

Last modified 7 years ago

#29158 closed task (blessed) (fixed)

Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin

Reported by: celloexpressions's profile celloexpressions Owned by: helen's profile helen
Milestone: 4.7 Priority: normal
Severity: normal Version: 3.8
Component: Customize Keywords: color-contrast ui-feedback has-patch needs-testing needs-refresh
Focuses: ui, accessibility Cc:

Description (last modified by rianrietveld)

WordPress 3.8 (and the mp6 project) introduced a new design language for the WordPress admin, including a flatened design, higher contrast, more color, an icon font, and more. While it reskinned the Customizer, further work on the Customizer UI has proven difficult because the Customizer still lacks enough contrast for proper focus/hover/active styling.

Implementing things like Widgets, Menus, and Panels into the Customizer, has shown that most background colors need to be between #fff (the section heading color) and #eee. This makes it extremely difficult to create visual hierarchy between UI elements using color.

Customizer controls themselves are on a white background, not the off-white that is now used in wp-admin, making input elements stand out less and generally making something about the Customizer UI not feel very "WordPress". While the other accordion in the admin (in Menus) also uses this convention, it doesn't fit well in the Customizer since the Customizer accordion contains the primary actions.

The goal of this ticket is to introduce more breathing room for stronger visual hierarchy in new development with the Customizer, and to resolve the lack of contrast for focus/hover and active (open/current-section) states. Additionally, we should address concerns that the Customizer doesn't really match wp-admin (or the front-end toolbar, for that matter, which it should be more similar to given the front-end context) in the process.

MP6 did experiment with a considerably different design for the Customizer at one point, but it was pulled because the dark styling, which was keyed to color schemes, was too heavy, and felt more appropriate for a menu than for tools. However, one potential option for addressing this ticket is to re-explore color scheme integration, since color schemes are under-utilized in the Customizer. This is one approach I'm proposing, but not the only possible solution here. Many options have been explored, and I like this the best, but this is design so not everyone will. I'm open to anything that addresses the issues above.

The coming patch uses admin menu colors (keyed to colorschemes) for the navigation components of the Customizer, but uses wp-admin body styling (the off-white background and light UI) for the functional tools/controls regions of the Customizer. Not perfect, but an interesting proof-of-concept at the very least, and does address some of the issues with this approach in mp6.

Tracking label: #a11y-color

Attachments (23)

29158.colors.diff (9.5 KB) - added by celloexpressions 10 years ago.
customize-panels-3-alt.png (16.1 KB) - added by celloexpressions 10 years ago.
Failed experiment at improving contrast between inactive and active/hover/focus styling, with panels.
customize-panels-3-c.png (12.1 KB) - added by celloexpressions 10 years ago.
Failed (too many shades of gray, though likely to end up in 4.0) attempt to introduce more contrast/hierarchy but keep things very light.
customize-panels-4-default-colors.png (13.6 KB) - added by celloexpressions 10 years ago.
Initial attempt to re-introduce color schemes and stronger contrast/hierarchy, with the default colorscheme and 29158.colors.diff.
customize-menus-bad-visual-hierarchy.png (24.3 KB) - added by celloexpressions 10 years ago.
Insufficient range of shades (of gray) for good color-based visual hierarchy in Menu Customizer.
customize-section-open-panel-style.png (22.8 KB) - added by celloexpressions 9 years ago.
Proposed design of "open" section if sections use panel-like side-sliding.
customize-section-open-panel-style.2.png (35.5 KB) - added by celloexpressions 9 years ago.
Proposed design options for "open" sections if sections use panel-like side-sliding.
labels.jpg (231.2 KB) - added by JohnPixle 9 years ago.
customizer.jpg (251.5 KB) - added by JohnPixle 9 years ago.
Proposed design for better hierarchy in the customizer accordion tabs
29158.borders.diff (3.5 KB) - added by celloexpressions 9 years ago.
Audit usage of borders in Customizer Navigation. Introduce clearer, higher-contrast hover/focus styling for navigation, with visual non-color focus indicators.
29158.borders.png (15.8 KB) - added by celloexpressions 9 years ago.
29158.borders.1.diff (3.5 KB) - added by celloexpressions 8 years ago.
refresh
29158-circle-shadow.PNG (18.9 KB) - added by celloexpressions 8 years ago.
Circular box shadow over arrows on focus/hover
customizer-contrast-i7.png (80.5 KB) - added by folletto 8 years ago.
Customizer Contrast: Normal + Active + Hover i7
29158.left-border.png (19.1 KB) - added by celloexpressions 8 years ago.
With 29158.left-border.diff.
29158.left-border.diff (6.2 KB) - added by celloexpressions 8 years ago.
Blue left borders, tied to color schemes, to match the device preview borders. Fix borders not being visible against the background color throughout the customizer.
29158.left-border.1.diff (6.7 KB) - added by celloexpressions 8 years ago.
Improve close button hover and focus styles.
29158.left-border.close.png (12.2 KB) - added by celloexpressions 8 years ago.
Hover (left) and focus (right) styles for the close button in 29158.left-border.1.diff.
29158.left-border.2.diff (5.5 KB) - added by celloexpressions 8 years ago.
29158.left-border.diff without the border-left on back arrows.
customizer-contrast-i9.png (76.1 KB) - added by folletto 7 years ago.
Customizer Contrast: Normal + Active + Hover (and close) i9
29158.i9.diff (8.6 KB) - added by celloexpressions 7 years ago.
Implements customizer-contrast-i9.png.
29158.i9.2.diff (12.6 KB) - added by celloexpressions 7 years ago.
Unify transitions to .15s (per @folletto, and any slower is generally not visible) and remove color schemes.
29158.i9.3.diff (13.8 KB) - added by celloexpressions 7 years ago.

Download all attachments as: .zip

Change History (148)

@celloexpressions
10 years ago

Failed experiment at improving contrast between inactive and active/hover/focus styling, with panels.

@celloexpressions
10 years ago

Failed (too many shades of gray, though likely to end up in 4.0) attempt to introduce more contrast/hierarchy but keep things very light.

@celloexpressions
10 years ago

Initial attempt to re-introduce color schemes and stronger contrast/hierarchy, with the default colorscheme and 29158.colors.diff.

@celloexpressions
10 years ago

Insufficient range of shades (of gray) for good color-based visual hierarchy in Menu Customizer.

#1 @folletto
10 years ago

Please note that as mentioned in #28979 the visual hierarchy could be hugely solved just by switching from accordions to slide-ins (as Widgets are), thus reducing any need of complex visual hierarchy solution, which would be just a stop-gap. ;)

#2 @celloexpressions
10 years ago

Also, a very important thing we need to resolve as part of this process is that the current focus styling for control sections and panel headers is horribly inadequate. We either need to achieve color-inversion, significant luminosity change, or add some other indicator like a border (not ideal since we'll also use that styling for open/active sections, unless we slide them over like panels and drop the accordion). See #28267 for more details.

#3 @dauidus
10 years ago

I would really appreciate a darker styling, and don't think something keyed to color schemes would present itself as too dark. As we stand in 4.0, its difficult to distinguish where one section ends and the next begins, particularly in sections with more than one option. When we also consider the coloring of standard buttons within the customizer, we begin to see a real disconnect in the overall styling. After all, settings in the Customizer should be easy to find and simple to navigate through. I'm just not getting this with the light grey color scheme, though.

Perhaps the disconnect when using a darker color scheme presents itself most in the secondary panels (the ones that slide in). No clear distinction is made between the "You are Customizing" title and the setting panel.

I understand that tying the Customizer colors to the chosen color scheme might not be the best option. But, it would provide a more cohesive UI and help direct the user to the desired areas.

#4 follow-up: @folletto
9 years ago

As we stand in 4.0, its difficult to distinguish where one section ends and the next begins, particularly in sections with more than one option.

This is an accordion issue, which surely could be reduced by a different color scheme, but in the end it will still be the issue of using accordions. If we switch to sliders for every block we will solve this issue once and for all. ;)

@celloexpressions
9 years ago

Proposed design of "open" section if sections use panel-like side-sliding.

@celloexpressions
9 years ago

Proposed design options for "open" sections if sections use panel-like side-sliding.

#5 in reply to: ↑ 4 @celloexpressions
9 years ago

Replying to folletto:

This is an accordion issue, which surely could be reduced by a different color scheme, but in the end it will still be the issue of using accordions. If we switch to sliders for every block we will solve this issue once and for all. ;)

I think our best approach is to do both - utilizing a broader range of colors to achieve adequate visual contrast, and doing a better job at organizing section and panel hierarchy appropriately.

I tried exploring some options for side-sliding accordion sections (screenshots above), and we're actually going to run into the same colors issue if we try to implement it in the current scheme (we either have input elements blending into the background (which the admin addresses with the global #f1f1f1 background) or a bunch of slightly different grays competing for attention). By leveraging a broader range of colors and removing the accordion behavior, we can achieve a visual and organizational distinction between navigation and content.

For example, when no section is open, everything is dark, but we can use bright (colorful) hover/focus states. Once a section is open, most of the visible space is on a light background, but the navigation controls at the top and bottom remain dark to provide a clear UI hierarchy. I think we should try using something like #000 for the hover/focus-states of the back/close buttons instead of the color there, to avoid making it distracting (since we removed the blue hover states from the light theme).

Changing the accordion behavior depends on #28709, but we may be able to do this for 4.1 depending on the timing. Also, one note: we should make #customize-info, and the panel-description sections retain the accordion behavior, since making those side-slide would be pretty inefficient.

#6 @folletto
9 years ago

I think our best approach is to do both - utilizing a broader range of colors to achieve adequate visual contrast, and doing a better job at organizing section and panel hierarchy appropriately.

I agree that these are separate issues.
That said, what "contrast" are we trying to achieve? Consider that there's a page on the side, so the main contrast needs to be with the page on the side, which must be kept in consideration in designing this panel. :)

With this I mean that if the panel uses different bands of color or solutions that don't make it perceived as a "single piece" it would create perceptual interference with the page on the side.

That's why of the solutions you propose above, the one with just a single color and no boxes is the one that works better: it's cleaner, understandable, and create a single object contrasting on the page to the right. :)

I have no preference on light vs dark choices, I feel both can work well (in the end, you can have a white or a black theme to the right, which we don't know), I just feel we shouldn't use multiple layers / tones there, but aim for a single one.

tl;dr: in your mockups above, I'd go for the leftmost ones.

#7 @celloexpressions
9 years ago

Once we implement side-sliding (a 4.2 thing at this point, unfortunately), I think we could explore a redesign along those lines, although that actually has less contrast as a whole, so we'll see. Removing borders and other visual elements would reduce the need for as much contrast.

@JohnPixle
9 years ago

#8 @JohnPixle
9 years ago

Looking into this, I think it reveals a further inconsistency in styling. I have to agree that indeed the customizer page does not blend nicely with the rest of the admin in terms of styling. Given the functionalities of the customizer page, I instantly make a connection between this page (customizer), the widgets page and the menus page. I attached the image above, to point a couple of things:

At the widgets page and the menus page, while the UI follows the same approach, the field labels are styled differently (highlighted in green). At the customizer, we see even a third style for the labels, which is quite similar to the main tabs.

A second inconsistency (highlighted in blue) is between the widget and menu titles, and the main tab at the customizer.

So, perhaps we could refine the hierarchy here and follow a consistent styling. Personally I think that the field labels at the customizer are quite emphasized. Personally I would go with the same styling which is used for the labels at the widgets page.

Ideally I would also suggest to change the styling of the labels at the menu page as well, but I guess it is another chapter

I will try to make some mockups for a proposed Customizer text styling later today or tomorrow. Let me know any thoughts!

@JohnPixle
9 years ago

Proposed design for better hierarchy in the customizer accordion tabs

#9 @JohnPixle
9 years ago

Above is a quick draft I designed as a suggestion. This one uses an inset for the current accordion tab title and content, and a color accent for the current accordion tab.

In the example I am showing a case where there are 2 field sets in the accordion content.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


9 years ago

#11 @celloexpressions
9 years ago

#31336 now has a patch for addressing the more fundamental issue of the accordions not being good UX here. Once that's resolved, we can circle back here to evaluate the visual design options within the more logically structured Customizer for improved contrast and color schemes.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


9 years ago

#13 @celloexpressions
9 years ago

  • Milestone changed from Awaiting Review to 4.3
  • Owner set to ocean90
  • Status changed from new to assigned

The latest designs for #31336 address the issues of contrast and hierarchy here pretty thoroughly, establishing a pattern of white elements being interactive juxtaposed against a gray background. Navigational elements also receive colored backgrounds on hover/focus, whereas inputs get borders/shadows for focus indication.

Unless anyone sees a need for further work here, we can close this when a first pass on #31336 is committed. (see screenshots and screencasts on #31336).

#14 @folletto
9 years ago

I agree. :)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


9 years ago

#16 follow-up: @celloexpressions
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

This is currently fixed in trunk by #31336. However, @helen has expressed concerns with the blue hover states introduced there; if we end up with a change there that doesn't provide adequate contrast for focus styles for accessibility, we'll need to reopen this.

#17 in reply to: ↑ 16 @hugobaeta
9 years ago

Replying to celloexpressions:

@helen has expressed concerns with the blue hover states introduced there; if we end up with a change there that doesn't provide adequate contrast for focus styles for accessibility, we'll need to reopen this.

I was trying to make sense of the many tickets around this, and this solution (that you proposed in #31336) seems to help with what @helen mentions, and make the most sense (notice, I'm looking at the hover colors specifically):

https://core.trac.wordpress.org/raw-attachment/ticket/31336/customize-ux-redesign.gif

#18 @ocean90
9 years ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

#19 @ocean90
9 years ago

  • Owner ocean90 deleted
  • Status changed from reopened to assigned

This ticket was mentioned in Slack in #design by ocean90. View the logs.


9 years ago

This ticket was mentioned in Slack in #design by stephdau. View the logs.


9 years ago

#22 @obenland
9 years ago

@hugobaeta, @ocean90: What's the status on this? With beta1 is one week away we should make a decision on this.

#23 @celloexpressions
9 years ago

  • Focuses accessibility added

This probably needs to become a task and slide into beta. We can't really not fix it/punt again at this point I feel like, especially with all of the related changes that have happened so far in 4.3 (#31336 and the corresponding unified approach menus took, but not doing menus yet and having some bits reverted with the blue). I have one more idea to propose here that focuses more on improved handling of borders than changing backgrounds/colors, which I'll put together this weekend if a solution isn't finalized before that. But ideally we need to start looking at a bunch of design proposals in the form of screenshots attached to this ticket.

Adding accessibility focus due to the severe lack of a visual indicator of focus that is one of the main issues we need to fix here after the blue was re-reverted.

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


9 years ago

@celloexpressions
9 years ago

Audit usage of borders in Customizer Navigation. Introduce clearer, higher-contrast hover/focus styling for navigation, with visual non-color focus indicators.

#25 @celloexpressions
9 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

29158.borders.diff takes another look at this, specifically focusing on improving visual focus styling for accessibility purposes (including better contrast for users with less-than-ideal screens).

This patch introduces darker borders and slightly darkens the text color to accentuate the extremely slight difference in background color that is currently in place. Additionally, rather than adding an even darker border, colored box-shadow, or other more distracting focus indicator, it implements an icon change that makes it easy to distinguish the hovered/focused item fr om the others. In practice, playing around with the patch, I think it works, but I'm interested in other opinions on this.

Leveraging borders as a means for improving contrast/distinction between elements is the broader proposed solution here, and would be the recommended way for developers to introduce hierarchy when color isn't enough in the Customizer. This allows us to keep the light UI without using too many different grays and while ensuring there is adequate contrast between elements of different hierarchies. I've audited the use of borders throughout the Customizer navigation for consistency in this patch as well.

Once we've resolved this for the main navigation and general governing principles, we can address more specific issues like unifying widgets and menus and improving visual contrast and hierarchy there (in #32679).

This ticket was mentioned in Slack in #design by marita. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


9 years ago

#28 @ocean90
9 years ago

  • Milestone changed from 4.3 to Future Release

Moving this out of 4.3 because it definitly needs more eyes, especially from designers if we want to change colors and such. This should probably have some variants too so we can run them through user tests to find the best combination of several ideas.

#29 @afercia
9 years ago

After the blue on hover/focus was reverted in 32823 see #31336, using just a shade of gray wouldn't be sufficient. Also, focus indicator shouldn't relay on color alone and secondary marker is required. 29158.borders.diff is an improvement since it uses also an icon change.

By the way I would propose to make an effort to establish a unique design pattern to be used also in other places in the admin, see for example #28599 or what Press This currently uses (see screenshot below).
Worth considering WordPress should have a unique way to indicate focus on this kind of menu items and users shouldn't be forced to learn new patterns depending on the different screens/components.

Menu items focus style in Press This:

https://cldup.com/gxI1O-FC6z.png

#30 @celloexpressions
9 years ago

29158.borders.diff has been implemented in the Customizer UI Experiments plugin to facilitate testing. Interested parties: please install and test that plugin and share back thoughts on the UI here. Anyone interested in making code changes via the plugin let me know and I can give you commit access; for mockups and discussing ideas, let's keep the discussion on this ticket.

After seeing the skin that WordPress.com has added (using light blues), I think we should definitely do everything we can to avoid that, unless we can find colors that feel better and more neutral. Given the stated intention (either above here, or on slack) to keep the Customizer as minimal as possible so as not to distract from the site preview, the subtle changes in the borders patch would probably work much better than something like what press this uses, at least for now.

That's not to say that the Customizer wouldn't benefit from a broader redesign from the ground up, but given the current UI I think the borders patch is the best path forward for now. Would love to see concepts for an entirely new Customizer UI eventually (only requirements being that it needs to include panels, sections, and controls, and the preview in some way).

#31 @afercia
9 years ago

From an accessibility point of view what the Customizer UI Experiments plugin does it's a clear improvement, see below without and with the plugin enabled:

https://cldup.com/FeQqbITd1c.png

The focus indication is given both by the subtle changes in the background color/borders and from the arrow's shape change so it's not conveyed by color alone but also by an additional visual clue. Will ask the accessibility team to have a look :)

Maybe the only place where focus is still unclear is on the reorder buttons:

https://cldup.com/ZAVr23QA6M.png

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 years ago

#33 @rianrietveld
9 years ago

  • Description modified (diff)

#34 @celloexpressions
8 years ago

  • Milestone changed from Future Release to 4.4

We should fix the reorder-arrow focus in another ticket. Does anyone have further design or accessibility feedback here, or it is ready for commit?

Due to current lack of design feedback and the need to fix the accessibility issues here, I think we should proceed with the scaled-down borders/icon approach in 29158.borders.diff, which is also testable with the Customizer UI Experiments plugin as noted above. Further improvements can be made in the future (including a potential ground-up redesign), but we need to fix the issues with the current design in the meantime and these changes are relatively low-impact. Note that the patch also fixes several inconsistencies with the use of borders in the UI, in addition to refining the focus styling.

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


8 years ago

#36 @celloexpressions
8 years ago

  • Keywords commit added; needs-testing removed

29158.borders.diff is ready for commit.

The proposed changes are fairly low-impact, making the design intent clearer while working within the design concepts that we currently have. The only thing here that may be at all controversial would be the icon change on hover/focus. However, viable alternatives have not been proposed that wouldn't require a broader redesign. Let's get this fixed for the design we have now so that we can shift design focus to entirely new concepts for the Customizer. Based on the lack of feedback here, I don't think we have the designer resources to do anything more than this currently. However, we do have several people using it in the wild via the Customizer UI Experiments plugin.

#37 @wonderboymusic
8 years ago

  • Owner set to helen
  • Status changed from assigned to reviewing

@helen, will you please give this a glance

#38 @helen
8 years ago

I'll take the patch for a spin, but a summary of screenshots/quick screencast is needed here.

#39 @helen
8 years ago

  • Keywords needs-refresh added

Needs a refresh too it seems.

#40 @wonderboymusic
8 years ago

  • Keywords commit removed

@celloexpressions
8 years ago

refresh

#41 @celloexpressions
8 years ago

  • Keywords needs-refresh removed

29158.borders.1.diff is refreshed, this image is essentially the extent of the changes (same on mobile): 29158.borders.png.

#42 @DrewAPicture
8 years ago

  • Keywords has-screenshots added

29158.borders.1.diff still applies. What needs to happen to move this ticket forward?

This ticket was mentioned in Slack in #design by helen. View the logs.


8 years ago

#44 @hugobaeta
8 years ago

The last proposed approach does seem to improve a11y, the issue is that the changes don't really fit in well with the rest of the admin visual patterns. So doesn't Press This, but at least the way I see it is that both Press This and the Customizer live in a place outside the Admin, but they still need to feel like part of the admin experience. One great pattern Press This is introducing is the left mark for hovered/selected items. Did a quick experiment to try it out, don't really have time today to write a patch for it, but it was one tiny change in inspector to make this screenshot:

https://cldup.com/s_1tnwsDjK.png

Regarding the arrow change i saw in the previous proposal, I think it is particularly jarring. Maybe it's because of the spacial change in the pattern, I can't really tell... it just strikes me as a jarring change. I'd say the left blue bar is enough of a visual change indicator.

#46 @helen
8 years ago

  • Keywords needs-patch added; ui-feedback has-patch removed
  • Milestone changed from 4.4 to Future Release

No determined route, punt. I'm relying on visual designers to provide constructive feedback and alternatives, but I'll note that I'm a hard no on 29158.borders.1.diff.

#47 @celloexpressions
8 years ago

I'l note that there are some important things in the borders patch that clean up the use of borders throughout the Customizer (such as for panel/section headings). Some questions to address - are borders used as separators between navigational items? Should they also be used on heading elements, separated sections like menu locations and the themes heading? Why is there a bottom border but no top border on the main group of sections currently? Are there components of that patch other than the icon part that you would say are a hard no @helen? If I recall correctly it addresses those questions by consistently placing borders between all white UI and gray background elements.

The colored border seems out of place with the Customizer design as it currently stands, probably because of the use of color, which we've really stayed away from. I wonder if a gray border-type indicator would work better there or whether adjusting the spacing would help?

I'm pretty much out of ideas here, so if anyone else has suggestions please create screenshots and/or patches illustrating them. While I was hoping to get the accessibility issues fixed without a complete overhaul, maybe we should consider that fair game too if there's a compelling option. We really need a solution here though, this ticket is definitely showing its age.

@celloexpressions
8 years ago

Circular box shadow over arrows on focus/hover

#48 @celloexpressions
8 years ago

Tried one more concept - the circular box shadow notion that we've begun using elsewhere in the Customizer and the admin (see screenshot above, also pushed to the Customizer UI Experiments plugin). Because of the auto-focusing, we probably need to have it present on hover too to avoid looking weird, but it's kind of a lot. I'm not a huge fan in this context, but it's an option.

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


8 years ago

#50 @afercia
8 years ago

  • Keywords color-contrast added

@folletto
8 years ago

Customizer Contrast: Normal + Active + Hover i7

#51 @folletto
8 years ago

As a follow up to coordinate with the discussion we had on #31195, I took @hugobaeta's suggestion above and created a single mockup that coordinates both, in i7, attached.

I hope it helps. ;)

#52 @karmatosed
8 years ago

I'd +1 what @folletto has done. I would not like to add a circle around arrow or any new UI treatments in this case. I'd also like us to get this moving to bring consistency and then feedback to the widgets in #32679.

#53 @celloexpressions
8 years ago

I think we can probably get consensus on the border-left approach, and we should also incorporate the border-consistency changes in 29158.borders.1.diff.

We also need a solution for the back and close buttons - can we make a one-sided border feel right there? Maybe a border all the way around? They're a different case since it's one button at a time instead of a list of them. And they're also auto-focused, so the style can't be distracting. Maybe something like gray on focus and blue on hover could help, for whatever the visual marker ends up being?

#54 @folletto
8 years ago

I think we can probably get consensus on the border-left approach, and we should also incorporate the border-consistency changes

Cool. Can you add a screenshot for the changes? I'm not sure I get what these entail. :)

We also need a solution for the back and close buttons - can we make a one-sided border feel right there? Maybe a border all the way around? They're a different case since it's one button at a time instead of a list of them. And they're also auto-focused, so the style can't be distracting. Maybe something like gray on focus and blue on hover could help, for whatever the visual marker ends up being?

I think that's a separate issue: the initial state of the X button is causing a lot of troubles, and we should fix it not being auto-selected on open. There's a ticket for that in #33228 that I think should have priority and land before this one.

Having finally the X not auto-selected would allow to have clearer, sharper styles and would stop forcing us to find a balance between active state visibility and too much visibility that is limiting for both the goals we are trying to achieve.

Once #33228 lands, we can then proceed with a proper highlight state. :)

#55 follow-up: @celloexpressions
8 years ago

customizer-contrast-i7.png is the border-left approach :)

In addition to the close X, we need to worry about section back arrows being focused after expanding a section. Unless those also shouldn't be autofocused @afercia?

#56 in reply to: ↑ 55 @afercia
8 years ago

Replying to celloexpressions:

Unless those also shouldn't be autofocused @afercia?

Moving focus to the section back arrows is necessary otherwise focus would be lost. Re: initial focus, quoting from #33228:

as far as I can tell, moving initial focus to the Customizer is only necessary when the Customizer gets loaded in the iframe "overlay". Instead, when it loads in the normal customizer.php customize.php page, there's no need to change the native focus order

#57 @folletto
8 years ago

is the border-left approach :)

Yep, I was more wondering about the "we should also incorporate the border-consistency changes" bit. What are these changes? Same thing?

Moving focus to the section back arrows is necessary otherwise focus would be lost.

Can't we have an "external" element with focus, so it starts at a tabulation point that is hidden, before getting to the back? The hidden tab point might still behave as back. That would again allow the same crisp highlight without any loss of keyboard/focus navigation.

#58 @celloexpressions
8 years ago

The border-consistency changes are primarily top and bottom gray borders on sections, the customize actions heading, etc. although I'll need to go back and look at exactly which pieces we still need when we do the next patch. They shouldn't impact much visually.

It might not be the end of the world to have a highlight border on autofocused back borders, but it could also be a bit problematic. I think there should typically be a visible focus indicator at all times though, with the exception of the initial page load?

#59 @folletto
8 years ago

It might not be the end of the world to have a highlight border on autofocused back borders, but it could also be a bit problematic. I think there should typically be a visible focus indicator at all times though, with the exception of the initial page load?

The first load yes, shouldn't highlight by default.

For other actions, I'm not sure. In terms of flow what seems relevant is that if the cursor did actually move from the "outside focus" position, then it should focus on the correct item when moving down with focus-triggered actions. If instead it's all pure mouse, the highlight shouldn't be visible at any time (unless again explicitly triggered). But I'm aware it might be challenging.

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


8 years ago

#61 follow-up: @celloexpressions
8 years ago

Re: the discussion in #design, I agree that we can start with the border-left change, then continue on to address the back arrows. That continuation should remain in this ticket though, as it's part of the reduced scope regarding visual focus indicators for navigation elements. The rest of the issues here were largely resolved with #31336. The part of the borders patch that I want to preserve has to do with the header and footer, and the sections that are shown with spacing - it's subtle and not particularly noticeable at first.

#62 in reply to: ↑ 61 @melchoyce
8 years ago

Replying to celloexpressions:

Re: the discussion in #design, I agree that we can start with the border-left change, then continue on to address the back arrows. That continuation should remain in this ticket though, as it's part of the reduced scope regarding visual focus indicators for navigation elements. The rest of the issues here were largely resolved with #31336. The part of the borders patch that I want to preserve has to do with the header and footer, and the sections that are shown with spacing - it's subtle and not particularly noticeable at first.

Can you do some updated before/after screenshots of just what that patch includes?

@celloexpressions
8 years ago

Blue left borders, tied to color schemes, to match the device preview borders. Fix borders not being visible against the background color throughout the customizer.

#63 @celloexpressions
8 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.7

29158.left-border.diff cleans up the patch and follows the direction decided in last week's design meeting. I also added the left border to available widget items, as they follow a similar UI pattern. I added an updated screenshot, but since this is an interaction-oriented change, the patch should be tested for further feedback.

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


8 years ago

@celloexpressions
8 years ago

Improve close button hover and focus styles.

@celloexpressions
8 years ago

Hover (left) and focus (right) styles for the close button in 29158.left-border.1.diff.

#68 @celloexpressions
8 years ago

  • Keywords needs-testing added

29158.left-border.1.diff builds on 29158.left-border.diff to improve the focus styles on the close button. These are based on the styling of the device preview buttons, which are also initially on an #eee background. Note that the close button will no longer be focused on load with #33228, which is marked for commit.

Would be good to get some testing and feedback on this final solution so that we can make any tweaks and get this wrapped up.

#69 @afercia
8 years ago

In 38520:

Accessibility: Improve the Customizer and Theme Installer initial focus.

The Customizer and Theme Installer open in full overlays that need to receive
focus. Also, keyboard navigation should be constrained within the overlays. Using
CSS visibility to hide all the content except the overlays, makes them the only
available and focusable content and allows browsers to handle focus natively.

See #29158.
Fixes #33228, #27705.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

#73 @helen
8 years ago

29158.left-border.diff seems fine except for the border on the back button, which is distracting given the autofocus (as was noted quite a while ago, I believe) and also because the background color animates in at a different pace, which looks very strange on hover. Can we commit a version that doesn't alter the back button? And then continue on into those icon buttons after that.

@celloexpressions
8 years ago

29158.left-border.diff without the border-left on back arrows.

#74 @celloexpressions
8 years ago

  • Keywords commit added

Thanks @helen!

29158.left-border.2.diff should be ready to commit, removing the back button left border from the previous patch. We've discussed that issue with it autofocusing multiple times, but hadn't tried the border yet (which I also didn't like). Focus styles for the back arrows and the close button (no longer autofocused) are the only remaining item after this, for which underlining the icon (screenshot above) is my best idea so far.

#75 @helen
8 years ago

In 38602:

Customizer: Better hover/focus state for section titles and available widgets.

The 4px border pattern is found in a number of places across the admin, including plugins, notices, and Press This.

props celloexpressions, folletto, hugobaeta.
see #29158.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


7 years ago

#78 @celloexpressions
7 years ago

  • Keywords needs-patch ui-feedback added; has-screenshots has-patch needs-testing commit removed

We need to come up with better hover/focus styles for the back arrows and the close button. We tried the left border, it did not work. I also tried adding an underline to the icon:

https://core.trac.wordpress.org/raw-attachment/ticket/29158/29158.left-border.close.png

The close button is no longer autofocused on load, so it should't be an issue to give it a nice clear style. However, back arrows are focused when opening a panel, so we need a clear focus style that is also acceptable whenever a panel/section is opened.

#79 @folletto
7 years ago

However, back arrows are focused when opening a panel, so we need a clear focus style that is also acceptable whenever a panel/section is opened.

Can't we fix that? I wouldn't try to update the style until that's fixed too.

Even just moving the selection to the first item in the list instead of the close button would work maybe?

#80 @celloexpressions
7 years ago

I wouldn't be opposed to focusing the first control instead of the back arrow when opening a section, would that work @afercia? Or will the associated labels then be skipped?

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

@folletto
7 years ago

Customizer Contrast: Normal + Active + Hover (and close) i9

#82 @folletto
7 years ago

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

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#84 @celloexpressions
7 years ago

There is an issue with the themes section in trunk, see https://wordpress.slack.com/archives/core-customize/p1475517778001564. We can fix that during beta if #37661 (which would replace that section) doesn't make it into 4.7.

#85 @celloexpressions
7 years ago

See #38222 for the themes issue. We need to discuss @folletto's proposal during this week's design meeting.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#87 @celloexpressions
7 years ago

  • Owner changed from helen to celloexpressions

I'll make a new patch for @folletto's i9 above, which was agreed on in the design meeting today.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#89 @celloexpressions
7 years ago

I'm waiting for an initial commit on #37661 to work on this.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


7 years ago

#93 @celloexpressions
7 years ago

  • Keywords has-patch needs-testing added; needs-patch removed
  • Owner changed from celloexpressions to helen

29158.i9.diff refines the solution here, aligns better with the new themes panel styling, and implements customizer-contrast-i9.png. It also adjusts the initial focus when opening a section cc @afercia.

Assigning to @helen for review since you did the initial commit.

@celloexpressions
7 years ago

Unify transitions to .15s (per @folletto, and any slower is generally not visible) and remove color schemes.

#94 @celloexpressions
7 years ago

29158.i9.2.diff unifies the transitions per the comment above, and also removes color schemes.

The color schemes define colors that we're using the default color of (#0073aa). But we use it much differently here that the way it's used elsewhere, such as in the admin menu, and there are numerous secondary colors tinted accordingly with this base color. At this point, I think the best solution is to stop applying color schemes to the customizer entirely (primary buttons are probably the only thing that will still change).

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#97 @afercia
7 years ago

Tested the latest patch, worth noting when opening a panel, focus is not moved anywhere. Without the patch applied, focus is moved to the "back" arrow which is preferable (though doing so, the "Close" and "Save" controls are skipped). Now instead, when a panel slides in, there's no element focused. Using just the keyboard, this would require an additional tab key press to get the back arrow focused (though some browsers completely loses focus). Using Safari+VoiceOver, after the additional tab key press, focus goes to the devices preview buttons, clear indication that focus is lost.

Quickly dumping on my console focusTarget for both the Panel and Section, gives me a jQuery object with length: 0.

#98 @afercia
7 years ago

So, not sure this is correct:
focusTarget = content.find( ':focusable' ).first() || backBtn,
the first part is always true because it is always something (a jQuery object) even if jQuery doesn't match any element.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

#100 @celloexpressions
7 years ago

  • Type changed from enhancement to task (blessed)

29158.i9.3.diff restores the hovers on hover to match the focus style per @helen. @folletto - could you elaborate on why they shouldn't be the same or the border shouldn't be used on hover? Want to give you a chance to clarify before we finalize this direction.

Patch also refreshes and tries to fix the focus selector based on what some of the other things in the customizer JS are doing, but it still seems to fall back to the back button for me...

Transitioning to a task per @helen. We're close but need a couple of more tweaks to close this out.

#101 @folletto
7 years ago

could you elaborate on why they shouldn't be the same or the border shouldn't be used on hover? Want to give you a chance to clarify before we finalize this direction.

There are multiple reasons:

  1. Interaction — mouse and keyboard are two separate input methods, and the fundamental interaction design paradigm of the combination of these modalities has at its foundation to have two different highlights to specify focus. Since mouse and keyboard act and move in different ways, we have the ability to target them independently.
  2. Weight — mouse and keyboard are inherently different in their behaviour too. The mouse pointer is often enough to signify where the user is and clicks. As a reference, many desktop UI guidelines don't even provide a hover in many instances, but they ALL provide keyboard navigation. Adding a styling to hover is in many instances an extra on top of not really requiring anything, while adding a styling on keyboard is a fundamental requirement, and it has to be evident because the user doesn't know where the focus is going to jump in the next tabulation.
  3. Standard — the standard provides both for independent styling — for the reasons above.

There are instances where focus and hover can conflate in a single styling. Sometimes there are limited options, sometimes there is a need of higher visibility.

In this case however we have a situation where the two aren't just possible, but we also already have a design that make them perfectly interlocking (an element can have both focus and hover and the styling is designed to work combining them properly). We have ready a solution that is already optimal in many ways.

Given we are perfectly following the interaction models, and we already have a proper solution to deal with focus and hover, I see no reason to revert to a less optimal case of having the stylings conflated into one, unless there's a strong reason — or a better design. :)

Last edited 7 years ago by folletto (previous) (diff)

#102 @celloexpressions
7 years ago

I'm realizing that for panels, we'll need to either autofocus the back arrow, the help icon, or the first child section heading. The previous patch's behavior required tabbing to get "in" to the section/panel after it opened, but still constrains tabbing within the opened section. Is that an option @afercia? If not we'll need to decide which focus target is best and know that it'll show the new border styling.

For what it's worth, I find visually-clear hover styles extremely helpful in both seeing more generally where the cursor is and where it can click. Cursors tend to be kind of hard to see/focus on in a lot of contexts. I generally prefer using touch over mouse anyway, but that's something to consider. In terms of this ticket, I don't necessarily have an opinion either way since I know I'm biased here.

#103 @folletto
7 years ago

I'm realizing that for panels, we'll need to either autofocus the back arrow, the help icon, or the first child section heading.

Could you add an image with a screenshot of how the three will look?

#104 @helen
7 years ago

I think we may disagree at a pretty low level about hover and focus being different - I find them to frequently be the same meaning: "this is where you are currently navigated to", whether that's with a mouse pointer or keyboard/whatever focus. This also ends up reflected when you click on a thing you were hovering on, which will get the focus style - sometimes this is fine, but it's more often very distracted, leading to people doing things like blurring after a click and so forth. I guess coming from this angle, I don't see a compelling reason in this instance to make the two different. It's not like better contrast only benefits keyboard users.

This ticket was mentioned in Slack in #meta-tracdev by ocean90. View the logs.


7 years ago

#106 @folletto
7 years ago

I agree, it's a frequent oversight to conflate the two as a single interaction, even when the fundamentals of human-computer interaction I explained above translate clearly to the UI. Happens far too often even in instances where it's not necessary.

Without getting to deep in HCI fundamentals that are probably more fitting a chat, I did a review and the issue you raised seems of a different nature:

leading to people doing things like blurring after a click and so forth

Analyzing this behaviour we can split in two aspects of the issue:

  1. Sticky Back — I've noticed this many times too. This issue is more visible when a user navigates in a section an back, given the original item remains selected. Which makes sense from a certain perspective for sure, but it also keeps highlighting an item it should be neutral (on back navigation). That's something we can address (I'm not sure on the accessibility reasons about it, they should be reviewed before moving).
  2. Focus on Click — The issue of triggering on click instead is present but minor, because once clicked the the new panel appears, making any potential focus state to be immediately hidden. The oddity here is that while it's formally correct to highlight the item, it fails in the customizer: the item shouldn't get a focus status on click because the focus has been transferred to the sub-panel.

My suggestion would be to keep the ticket as it was with the standard implementation of two interlocking and unified styles, and push for a solution to the more specific issue you raised in a separate ticket.

That said, I’m aware you have the final word, so up to you, I think with this second answer I gave you all the elements to decide. Either way, I’d still open the ticket mentioned above to discuss that problem and see if we can find a good accessible solution, because that's the bit that annoys us both. :)

#107 @celloexpressions
7 years ago

I think my preference is to match the two styles here for now, after trying both versions. We have to keep the autofocusing on open/close in a lot of places here, so I'd rather have that style be familiar to primarily-mouse users before they see it "unintentionally".

I definitely see your points about considering these interactions separately, and we should do that when we redesign this interface more broadly from the ground up (hopefully soonish, initial ideas encouraged).

#108 follow-up: @celloexpressions
7 years ago

@afercia is the behavior of the current patch - not moving focus at all when opening a section panel - okay? Since only the visible section has focusable elements, I'm wondering if this might be an option. Otherwise, where do you think the best place to set focus to would be for a section and for a panel?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#110 @afercia
7 years ago

@celloexpressions ideally, focus should land on the first focusable element. Will test the latest patch as soon as possible.

#111 in reply to: ↑ 108 @afercia
7 years ago

Replying to celloexpressions:

@afercia is the behavior of the current patch - not moving focus at all when opening a section panel - okay?

Maybe I'm missing something but with 29158.i9.3.diff focus always goes to the "Back" button for me, which is okay.

#112 @celloexpressions
7 years ago

The back button is seeming like the answer in terms of accessibility. How do we feel about that relative to the visual impact for mouse/touch users? If we're okay with that, 29158.i9.3.diff is ready to go.

(in the patch, the back button is focused because there don't seem to be any other focusable elements to target according to the jQuery).

#113 @folletto
7 years ago

The approach above implied we had a "better" first element to focus, otherwise the user gets the highly evident option on back, breaking a bit the balance of the whole UI. I was asking if possible to select an element "off" page (ideal from the perspective of UI perception, not sure it's ideal from an accessibility perspective), or the first element of the list, instead of back (a compromise, still fairly blunt perception wise).

So if we can find a better first item other than back/close, would be better. If not, I guess we have no other choice, so we can just go for that.

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

This ticket was mentioned in Slack in #core by helen. View the logs.


7 years ago

#117 @helen
7 years ago

  • Keywords needs-refresh added

Needs a refresh and an assurance from @afercia that the focus behavior is correct :)

#118 @afercia
7 years ago

From an a11y perspective, focusing the Back button makes sense to me. Thinking at sections and panels – is that correct technically? ;) – as parts of an UI that "appear" on the page then focusing the first control is correct. I understand the concern related to visuals, but that's what the implemented focus style does, and an accessible interface should always have a clear indication of where keyboard focus is.

https://cldup.com/BktHIGhZ7k.png

Worth mentioning again that the "X" close and "Save/Publish" buttons are basically "skipped" when navigating with a keyboard or using a screen reader, but that's an outstanding issue in the Customizer that should (hopefully) solved in the next releases.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#120 @helen
7 years ago

I don't really know why there's a positioning change for .customize-panel-back:focus:before as it's making the arrow icon shift around in all of my browser testing, and I'm pretty sure all the rejections in the patch are for the theme installer that is no longer there, so I'm going to commit this without those changes. If the former change needs to be there for some combination of browser+OS that I missed, we can handle that separately.

#121 @helen
7 years ago

Actually, will also omit the changes to src/wp-admin/js/customize-controls.js since the behavior of focusing on the back button doesn't actually seem functionally different even with the patch - we should handle that in a separate ticket and spend time figuring out the correct behavior and a patch that works.

#122 @helen
7 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 39249:

Customize: More visible focus and hover states for close and back buttons.

props celloexpressions, folletto.
fixes #29158.

#123 @helen
7 years ago

This ticket has become unwieldy so I'd advise opening new tickets for issues moving forward. One thing I noted was that the theme install details view now no longer matches - if somebody has an opinion on if it should match (I guess it should?) and open a ticket that would be lovely.

#124 @helen
7 years ago

In 39301:

Autoprefixer for [39249].

Fixes one errant value and re-aligns some existing prefixed property values so they don't get doubled when precommit/postcss is run again in the future.

props davidakennedy.
see #29158.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

Note: See TracTickets for help on using tickets.