Customizer: separate navigation from options UI for better UX by removing accordion behavior

[celloexpressions]

Per several design concepts and discussions with @folletto since the Panels API was introduced in WordPress 4.0, the current "accordion" behavior of the Customizer controls area is fundamentally flawed. Sections should slide-in similarly to panels, allowing users to focus on the contents of the active section more easily and separating the navigation from the content/controls in the Customizer.

The coming patch implements this behavior. There are a few quirks including the panel-back buttons needing improvement and widgets bumping out of the section contents when their controls are expanded (need @westonruter to look at that).

This fixes many of the issues in #29158, and once this is complete we can circle back there to improve things like focus states.

Backwards-compatibility is likely to break for custom section types, but thanks to the 4.1 JavaScript APIs and by keeping most of the underlying class names and CSS structure intact, issues should be reasonably minimal.

[celloexpressions]

Most recent conceptual design from @folletto.

[celloexpressions]

Use sliding instead of accordions in the Customizer, unify/clarify section and panel headings and descriptions/help toggles.

[celloexpressions]

Quick walkthrough of the Customizer with the patch applied

[ocean90]

Nice! :-)

Some thoughts:

• After adding a new widget I get this: ​https://cloudup.com/iM66LRgWy54
• Keyboard a11y: Between the back arrow and the help icon is something focusable. After pressing return I get this: ​https://cloudup.com/iTmkVjIK765
• a11y: After a slide there is no indication that the back element has focus.
• Should the available widgets panel still breaking out? Some user tests would help, I think.
• Context lost? The "You are customizing" header is not visible anymore if you open a section. I've noticed this while editing a single sidebar (Am I still editing widgets?). Not sure if this is a real issue.

[folletto]

Should the available widgets panel still breaking out? Some user tests would help, I think.

My initial perspective would be to not break out as suggested, mostly because your focus would be on the panel, so there's no need for "context" in seeing the previous panel too. Also would help making it work out of the box on mobile (I guess?).

That said... I think it's a minor detail in terms of UX. :)

Context lost? The "You are customizing" header is not visible anymore if you open a section. I've noticed this while editing a single sidebar (Am I still editing widgets?). Not sure if this is a real issue.

This is the only thing I was keeping in mind while designing the above. I'm not sure on the answer either. The fact that yo as a user are actually diving in/out and you have the actual preview site open on the right might be more than enough, but still it's something I tried to add back in the design (failing, at the moment).

So, not sure. :)

[celloexpressions]

Replying to ocean90:

• After adding a new widget I get this: ​https://cloudup.com/iM66LRgWy54

As do I, which is the same issue as mentioned above where something goes horribly wrong when a widget control is expanded (since adding a widget triggers expanding it). I couldn't figure out why, but I'm guessing westonruter may have an idea.

• Keyboard a11y: Between the back arrow and the help icon is something focusable. After pressing return I get this: ​https://cloudup.com/iTmkVjIK765

We should probably move focus to the back button for sections (right now it stays on .accordion-section-title, so you have an extra tab).

• a11y: After a slide there is no indication that the back element has focus.

It actually doesn't have focus, per above :) But we do need some focus/hover styling for that element, probably matching the top-level hover states.

• Should the available widgets panel still breaking out? Some user tests would help, I think.

I'd say definitely, when the screen is large enough. For the user, seeing the widget added to the sidebar (popping in at the bottom) right after you clicked it is comforting ("ok, that worked"). It also creates issues around adding multiple widgets at once, and we'd definitely want it to be a separate bump-out panel for menus when that happens.

• Context lost? The "You are customizing" header is not visible anymore if you open a section. I've noticed this while editing a single sidebar (Am I still editing widgets?). Not sure if this is a real issue.

Maybe we could prefix the section title with the panel title in the sub-panel? "Widgets: Sidebar" or "Menus: Theme Locations", for example.

[folletto]

Maybe we could prefix the section title with the panel title in the sub-panel? "Widgets: Sidebar" or "Menus: Theme Locations", for example.

Yep. I wasn't sure about that... what would be the longest combination that we're going to design for?

An alternative approach could be to use a super-title (like the "You are customizing". Might add a bit of height, but can be worth it... :)

[DrewAPicture]

Interesting idea, one I would encourage you to continue working on for a future release.

Beta is T-3 weeks away, and I have serious concerns about our ability to adequately resource testing, iteration, and more testing again to get this right. Looking forward to seeing what you come up with here.

[ryan]

This is the first thing I've seen that doesn't feel like wrong way go back. I like it.

[celloexpressions]

I really think we should try to make this happen in 4.2 for the following reasons:

• This has been in progress for 8 months now, so while the actual implementation/patch is new, we've been discussing this change since during 4.0 development (spread across several tickets, IRC, and Slack).
• Many of the improvements in previous releases have built up to this. Most notably, the JS API introduced in 4.1 and removing direct dependence on accordion.js was a prerequisite to considering any changes here.
• This type of a UX change can't really be tested for usability. Ultimately, the theory behind it and the actual feel of using it needs to drive changes. @folletto has done a great job developing the theory and explaining why there are fundamental problems with the original "accordion" UI. As @ryan said, this feels like a much better approach that solves a number of ongoing issues, complaints, and, potentially, general dislike of the Customizer. When it comes down to it, we're just going to need to pull the trigger and make the change.
• These changes can't be implemented in a plugin or without a deeply involved core patch. But, they are all UI-level, so we don't risk breaking things too badly as long as we do the obvious things like accessibility (and this will actually improve accessibility in terms of color contrast and focus styles).
• This complements the mobile improvements to the Customizer in 4.1; the Customizer is basically unusable on mobile with the accordion UI, even with our recent improvements.
• This is closely related to the Customizer Theme Switcher project, which introduces a "backwards" panel with opposite sliding. Eliminating vertical sliding with accordions makes the new layer of hierarchy much clearer and more natural. It also helps inform some of the UI decisions we've been having trouble with in terms of the top-level section heading title/icon.

Based on the amount of testing that the sorts of patches usually get for the Customizer, we're unlikely to catch most major issues that may exist until after a first-pass is committed even if we were to spend a lot of time testing ahead of time. Patches on this ticket are also likely to stale quickly due to their scale.

Next steps would be to sort through some of the more detailed things that may get tweaked here and make design changes, as well as fixing anything functionally broken.

[lessbloat]

Overall I like it. A few initial thoughts:

1) Looks like customize.php needs a refresh. Tried to apply the patch to test it and got:

Hunk #1 FAILED at 143.
1 out of 1 hunk FAILED -- saving rejects to file src/wp-admin/customize.php.rej

I'd love to take it for a spin once this is resolved.

2) Usability testing

This type of a UX change can't really be tested for usability.

I'd have to disagree with this statement. @folletto has access to a usertesting.com account with credits. I'd encourage you guys to do the following:

1) Come up with a short list of scenarios that you believe this new functionality will improve.
2) Use a test server to create a basic core install of WP.
3) Test your list of scenarios on the existing customizer (with 3-5 people) as a baseline. Doing this should highlight the most common pain points with the existing customizer implementation.
4) The test this new implementation with 3-5 people. This should highlight a number of things that you may want to tweak with the new proposed implementation before shipping it.
5) Fix the common friction points, and retest until at least 2 people make it through your scenarios without any friction.

It's admittedly a fair amount of work, but I'd highly encourage going the extra mile with a change of this size. You're design will be that much more polished as a result.

3) Context

Context lost?

This is my other major concern. Especially as you get a couple of levels deep into the customizer (like with widgets). RE: customizer-slidein-i1.png - Have you guys considered having some sort of one click "menu" link to take you back to the main menu (first screen) without having to click back 5 times?

[celloexpressions]

Patch refreshed - that part was duplicated in the Customizer Theme Switcher merge patch.

[celloexpressions]

Refresh customize.php for Customizer Theme Switcher core merge (CSS still needs updating for the themes section).

[celloexpressions]

Fix the now-in-core themes section styling.

[folletto]

Updated design with a prefixed sup-title.

[designsimply]

What is the reasoning behind sliding the themes panel in from the left as opposed to sliding it in from the right to be consistent with how the widgets panel works?

Whatever route is chosen in the end, I think themes and widgets should line up and get a consistent UI treatment. The UX for them seems to be diverging, but I think they should stay consistent.

[folletto]

What is the reasoning behind sliding the themes panel in from the left as opposed to sliding it in from the right to be consistent with how the widgets panel works?

My .02£: The reason is to show to the user the correct information architecture in a subtle way, which is, top-to-bottom: theme → customization menu → customization details → actual theme preview.

That said, this would be just a nudge and shouldn't damage the overall usability. It's more a target to aim to, not something that should impact the design just for the sake of it. :)

[westonruter]

Note that dragging widgets between widget areas currently kinda depends on there being vertically-stacked accordion sections. I'm not sure if a drag/drop UI would be possible if each widget area section behaved like a separate panel.

[celloexpressions]

Replying to westonruter:

Note that dragging widgets between widget areas currently kinda depends on there being vertically-stacked accordion sections. I'm not sure if a drag/drop UI would be possible if each widget area section behaved like a separate panel.

I wouldn't mind losing that feature for this (the drag/drop part), but we could always have the custom widget area customizer section retain accordion behavior as an override if we really want to keep it.

[celloexpressions]

Once we have an updated design that addresses the user testing analysis (​https://make.wordpress.org/design/2015/03/15/usability-testing-theme-switcher/), I can do a new patch. Let's make this a priority for the Customizer for 4.3.

The only change I'd propose as of now would be adding a back arrow back to the top-level as a way to address users thinking that they needed to save & publish within every section. I believe we'd also still need to implement breadcrumbs, if we want to do that based off of @folletto's latest design here.

[celloexpressions]

Walkthrough with 31336.4.diff.

[celloexpressions]

Refresh, add hover & focus states, clean up panel back arrow setup.

[celloexpressions]

31336.4.diff​ is a refresh for 4.3 alpha and contains a few other fixes for issues regarding things like the panel back arrow. Most notably, I added hover and focus styling, which now introduces a fair amount of color and contrast. In addition to making the focus states much clearer, I think this makes it much easier to visualize the different clickable regions for mouse users. I think it's important to retain some visual distinction between sections and panels at the top level, though, so I kept the two-toned approach for panels as a distinguisher. See the brief screencast video above.

I should also note that I think the section heading UI needs to be on a white background so that it contrasts with the gray background that's now behind the controls in regular sections (to match the admin and make inputs stand out better). I think we should design it out fully for regular sections and panels first, then look at how we'll need to adjust for widgets and menus (such as adding the extra layer of hierarchy for the add-item panels on mobile). Still need to flesh out the breadcrumbs idea in terms of design, but I think that could help with preserving context. I'd be interested in seeing how the latest patch tests for usability, as well as further design thoughts now that the dust has settled around the theme switching components.

Also, it looks like expanding widget controls now jumps out of the sidebar section - I'm having trouble locating the exact issue, but it looks related to the fact that much of the widget control expansion API is reused from the section expanded/collapsed state API. Any ideas there @westonruter?

[folletto]

I think it's important to retain some visual distinction between sections and panels at the top level, though, so I kept the two-toned approach for panels as a distinguisher.

I'm not sure about this: with a slider approach, there's no difference for a user perspective, and the section/panel distinction becomes just a technical detail (in terms of UX). I wouldn't make them any different in terms of UI.

how the latest patch tests for usability, as well as further design thoughts now that the dust has settled around the theme switching components.

Agreed. The above seems a solid approach worth testing. Going white for navigation elements and background for "content" feels clearer. :)

[westonruter]

Replying to celloexpressions:

Also, it looks like expanding widget controls now jumps out of the sidebar section - I'm having trouble locating the exact issue, but it looks related to the fact that much of the widget control expansion API is reused from the section expanded/collapsed state API. Any ideas there @westonruter?

​This function is the culprit:

/**
 * Expand the accordion section containing a control
 */
expandControlSection: function() {
        api.Control.prototype.expand.call( this );
},

This method gets called whenever the control is expanded. So the changes you've made to Section.onChangeExpanded need to be modified to do nothing if the section is already expanded.

[folletto]

i2 of the slide-in approach.

[folletto]

Added another iteration (i3) of the headers and slide-in/out navigation, to align with the approach taken in the patch above and give some uniformity across all panels. I also added a few extra screens just to give more context, even if the header is meant to be the same everywhere.

[celloexpressions]

Implement latest design from @folletto, including add-widgets for mobile and fixing widget-expansion.

[celloexpressions]

31336.5.diff​ implements the latest design from @folletto and fixes remaining issues with bugs ranging from inconsistent grays/whites to the widget-expansion issues. I've reviewed basic keyboard accessibility and we should have an improvement with this since there are much better focus states now. Could use a thorough accessibility audit after a first pass makes it in.

I think this is ready for final commit review. If anything comes up, please let me know. We need to get this in ASAP to continue iterating on the design of menus in the Customizer, which will align with these changes per the latest design. At this point, Menu Customizer will assume this patch is applied (or committed), at least in terms of CSS.

The design has probably evolved enough here to also close #29158, especially with the improvements to the handling of different shades of grays and white, establishing a clear pattern of white backgrounds for interactive UI elements including both navigational elements and input fields, with bolder colored hover/focus states for navigational elements only. The only remaining decision would be whether or not to key the hover/focus styles to color schemes.

The flow is feeling really good now for both desktop and mobile, so it could be a nice exercise to do some before/after on make/flow if anyone's interested. Screencast coming soon here, in case the grays get messed up in the gif, it's very close to what folletto proposed.

I'll also note that this may cause bc issues with custom sections that would be simply unavoidable, so it'll be good to get it in as early as possible to allow for ample testing.

[celloexpressions]

Mobile flow with 31336.5.diff.

[afercia]

Please consider any UI control should be built with semantic elements that have ​native support for keyboard interaction, for example:
<span class="customize-help-toggle dashicons dashicons-editor-help" tabindex="0">
it would be nice to don't introduce new span or div elements used this way, we already changed some of them see for example: #32227. Additionally, since this specific control toggles a "help" panel, it should also use an aria-expanded attribute.

[folletto]

Customizer header question mark toggle state

[folletto]

From a visual and flow perspective looks good to me. I'd do some testing to make sure there are no troubles, but seems fine to me.

I also attached a visual concept for the (?) toggle state. ;)

[obenland]

What do you think about removing the gray background from panel arrows? I feel like it's a differentiation we make that might not be really important to users, and possibly confusing.

[obenland]

Are there different transition speeds between panels and sections? Panels feel snappier.

[celloexpressions]

Accessibility fixes.

[celloexpressions]

Accessibility issues should be fixed in .6. @folletto it doesn't work great to have the full margin under the arrow because it just gets too narrow for most sentences, but other than that that's very similar to what it does currently. Any further thoughts on that?

Panel and section speeds are the same (.18s), but I think something's a bit off with the panel animation (and always has been - this patch doesn't change that), which makes it seem different. Specifically it gets stuck halfway and then skips the end of it or something. We could take another look at that later. In terms of panels vs. top-level sections, you get something fundamentally different after clicking on one (more navigation vs. actual controls to interact with), so even if the distinction doesn't matter for the average user, I think having it there will add some comfort and expectation for experienced users (vs. being unsure what you'll get after opening it if you're using a new theme or plugin with panels, for example).

@ocean90: do you think we can get a first-pass in by the end of the week?

[folletto]

Customizer header question mark toggle state (i2)

[folletto]

it doesn't work great to have the full margin under the arrow because it just gets too narrow for most sentences, but other than that that's very similar to what it does currently. Any further thoughts on that?

We can do then this simple variation. Doesn't look as good to me (and to be hones, I think that the ? isn't super effective, but this is not the time to review that).

In terms of panels vs. top-level sections, you get something fundamentally different after clicking on one (more navigation vs. actual controls to interact with), so even if the distinction doesn't matter for the average user, I think having it there will add some comfort and expectation for experienced users (vs. being unsure what you'll get after opening it if you're using a new theme or plugin with panels, for example).

We are standardizing them, and while it wouldn't likely cause any issue, it's weird to have two different things trigger the same interaction model. You always get what you click on, regardless if it's further navigation or interaction tools.

So I'd make them all identical with the clean arrow to the right as in the latest mockup.

Can we also align the search widget color and spacing? Feels a bit weird to have search on top fixed in gray and things scrolling below: gray is always background, so shouldn't stay "above" other elements.

[ocean90]

Feedback for 31336.6.diff​:

• I think the Customizer should get the same background color (#eeeeee ) as the admin (#f1f1f1) has.
• <?php _e( 'Customizing' ); echo ' &#9656; '; _e( 'Widgets' ); ?> should be one string so the arrow can be flipped for RTL.
• A widget can suddenly disappear: ​https://cloudup.com/c_QRWhciccQ
• The animation is broken on iOS and needs to be disabled for .customize-panel-back, see .ios .control-panel-back: ​https://cloudup.com/cCkB__QgYo9
• Tab order: a.customize-controls-close is focussed initially, clicking tab once doesn't focus something, at least it's not visible. I would expect that the help icon gets focussed. (Chrome 43)
• Since a section slides now too, do we really need to visually distinguish between a section and a panel? I don't think so.
• I noticed the different transition too, should be fixed.
• It's odd, that you can't click the whole panel title to close the current panel. Again, I don't think a user needs to know if she/he is seeing a section or a panel.
• Am I the only one who is missing keyboard navigation to return to the previous panel/section?
• I think the help toggle should be a bit lighter, #555 instead of #000.

[kuus]

Am I the only one who is missing keyboard navigation to return to the previous panel/section?

I miss it too! It would be a great addition

[ryan]

Important UI tickets like this really need screenshots of patches, particularly mobile screenshots.

[valendesigns]

When the latest patch is applied and I view the panel description .customize-panel-description there is no top padding or border, but the screenshots above seem to have that added. Did something change between patches? I'll add a screenshot of what I'm seeing.

[valendesigns]

Also, the help icon is missing a hover and focus state.

[valendesigns]

The previous patch didn't apply cleanly so I created 31336.7.diff​ to solve that and a couple other minor issues.

• Added hover/active/focus state to the help icon
• Set help icon color to #555
• Added top border and fixed padding for .customize-panel-description

[celloexpressions]

Misc. fixes, see comment.

[celloexpressions]

31336.8.diff​:

Panel description design now matches @folletto's latest design, and has a hover state for the icon.

I think the gray padding around widgets search is actually the correct color - that part is the only non-interact-able region in the add-widget panel. That being said, we should rethink the color patterns for widgets, add-widgets, menus, and add-menus. Let's do that in a future pass or other ticket, potentially after Menu Customizer is merged.

Replying to ocean90:

• I think the Customizer should get the same background color (#eeeeee ) as the admin (#f1f1f1) has.

I was leaning towards saying #eee, but then I realized that if we go lighter we constrain the range of usable grays even smaller than it was before. While we're mostly fixing these issues by being smarter about the patterns of white and gray that we establish, I'm really worried about reducing the contrast below the #eee that it currently is (and that the Customizer had had for some time now). We don't match the rest of the admin much at all in terms of broader UI patterns (ex. white navigation, vs. darker), so I'm not too concerned about the slight difference. On an average monitor it looks slightly better with the increased contrast that #eee provides, whereas I'm guessing it may be opposite on a higher-end screen. I'd rather design for something that is less likely to break or appear overly washed-out on a majority of users' devices. #eee is also used in a bunch of different places, not just that one background color, so I don't think we should change it unless there's another reason besides matching the admin.

• <?php _e( 'Customizing' ); echo ' &#9656; '; _e( 'Widgets' ); ?> should be one string so the arrow can be flipped for RTL.

Widgets is the dynamic panel title, so we can't fully combine them. In the latest patch, I added the arrow to the customizing string.

• A widget can suddenly disappear: ​https://cloudup.com/c_QRWhciccQ

It's hidden when it's dragged out of the widget region, which is a bit odd but could be argued as expected behavior. Other than the header part, this is caused by an overflow: hidden in common.css on .accordion-section-content, which I'm not sure that we should change or override.

Also, since this flows so much better, I think we're fine with losing the ability to drag widgets between areas, since there's still the move-to-area functionality in reordering mode.

• The animation is broken on iOS and needs to be disabled for .customize-panel-back, see .ios .control-panel-back: ​https://cloudup.com/cCkB__QgYo9

Should be fixed, but needs testing.

• Tab order: a.customize-controls-close is focussed initially, clicking tab once doesn't focus something, at least it's not visible. I would expect that the help icon gets focussed. (Chrome 43)

Looks like that was getting added in JS. Should be fixed now.

• Since a section slides now too, do we really need to visually distinguish between a section and a panel? I don't think so.

If someone else wants to patch it, go for it. But I still disagree. While the general UX is similar, panels and sections are fundamentally different, which is why we didn't go with an API that simply allowed nested sections when panels were first introduced. While it may not matter much to users, the UI should at least hint at the distinction, and I don't see it hurting anything.

• I noticed the different transition too, should be fixed.

I'm not sure that it can be fixed, unfortunately. We could investigate further when things stabilize after a first-pass is committed.

• It's odd, that you can't click the whole panel title to close the current panel. Again, I don't think a user needs to know if she/he is seeing a section or a panel.

We can't functionally change that because of the help toggle (and future potential screen options toggles). So if we want it consistent we'd have to reduce to only the arrow on section headings to be clickable (or at least to appear clickable).

• Am I the only one who is missing keyboard navigation to return to the previous panel/section?

It's at the top in the panel/section headers, just like for mouse and touch users. If we want to hide top-level or previous-level accordion-section-title tab-ability we could do that, and then they'd just go directly to the collapse link at the end of the section. But I don't think that's necessarily an improvement. Or if you mean something like esc, see #22237.

• I think the help toggle should be a bit lighter, #555 instead of #000.

Fixed.

I really think we should get a first-pass committed here so that fixes to all of these little details can be more easily patched by others without running into duplicated efforts. As of right now, likely due to the size of the patch for the initial overall change, it's difficult for others to iterate on these patches, and then when @valendesigns did (just fine), I was concurrently working on an iteration and had to merge them.

[ocean90]

Replying to celloexpressions:

#eee is also used in a bunch of different places, not just that one background color, so I don't think we should change it unless there's another reason besides matching the admin.

I noticed this for descriptions. The color of descriptions is #666, which results in a contrast ratio of 4.95:1, with #f1f1f1 we would have 5.08:1.

Widgets is the dynamic panel title, so we can't fully combine them. In the latest patch, I added the arrow to the customizing string.

The string is hardcoded in WP_Customize_Widgets->output_widget_control_templates() so we should change it there too. A better approach would be __( 'Customizing ▸ %s' ) with a translator comment explaining the placeholder and the unicode character. (Context is wrong here.)

It's hidden when it's dragged out of the widget region, which is a bit odd but could be argued as expected behavior.

That's definitely not expected and doesn't exist without the patch.

The animation is broken on iOS and needs to be disabled for .customize-panel-back, see .ios .control-panel-back: ​https://cloudup.com/cCkB__QgYo9

Should be fixed, but needs testing.

Sadly not, needs further investigation. Calling this a blocker since I don't want to handle this again late in the cycle. (Previously r32103.)

Since a section slides now too, do we really need to visually distinguish between a section and a panel? I don't think so.

If someone else wants to patch it, go for it. But I still disagree. While the general UX is similar, panels and sections are fundamentally different, which is why we didn't go with an API that simply allowed nested sections when panels were first introduced. While it may not matter much to users, the UI should at least hint at the distinction, and I don't see it hurting anything.

@folletto What do you think? I think the background color around the arrow for panels is a bit noisy and featureless.

• I noticed the different transition too, should be fixed.

I'm not sure that it can be fixed, unfortunately. We could investigate further when things stabilize after a first-pass is committed.

We should at least try it, but it's minor for now.

• It's odd, that you can't click the whole panel title to close the current panel. Again, I don't think a user needs to know if she/he is seeing a section or a panel.

We can't functionally change that because of the help toggle (and future potential screen options toggles). So if we want it consistent we'd have to reduce to only the arrow on section headings to be clickable (or at least to appear clickable).

I'm fine making only the arrow clickable for sections too. I think this would also solve the lack of focus indication after opening a section. Panel vs section: ​https://cloudup.com/ciLdL_TUu3f

@afercia The Customizer uses $title Press return or enter to open for screen readers to explain, that a section/panel can be opened. Is that clear enough? Is there something you would like to have changed in the latest patch in terms of a11c?

[folletto]

If someone else wants to patch it, go for it. But I still disagree. While the general UX is similar, panels and sections are fundamentally different, which is why we didn't go with an API that simply allowed nested sections when panels were first introduced. While it may not matter much to users, the UI should at least hint at the distinction, and I don't see it hurting anything.

@folletto What do you think? I think the background color around the arrow for panels is a bit noisy and featureless.

My perspective is pretty much the one I did in the mockups above: the UI should be the same. Because from an interaction perspective these are "the same" (i.e. when I click the same thing happens). I get there's a deep difference in the underlying framework, but the interaction is the same. Different UI elements should be introduced just for different interactions. It's a matter of pattern matching and overall clarity.

Granted, it's not a big deal, but polishes the interface further, which is a good thing even considering the other discussion about introducing icons. ;)

[valendesigns]

There are entirely way too many dependancies in the Customizer component right now. We need to start clearing out some of these tickets immediately. We can't afford to be doubling our efforts with the Menu Customizer UI.

This patch needs to land soon or be punted. What items are outstanding?

Nick, I can takeover for you if you want to focus on something else. I feel like you're spread thin right now.

[celloexpressions]

@valendesigns if you could handle the changes in the latest round of feedback that would be great. I've iterated on this patch a few too many times, and am low on time for the week at this point after all the Menu Customizer stuff the past two days.

In terms of the above the only other comment I'd have is that we should just darken descriptions if we're worried about the contrast there - I don't want to reduce the already tiny amount of fundamental contrast between UI and background (let's not get into that contrast ratio, although at least it's generally large background colors) just to change something that could be solved with a slightly darker text color. As long as it's 4.5:1 we should be fine, but could darken to maintain the current contrast if needed.

[afercia]

Replying to ocean90:

@afercia The Customizer uses $title Press return or enter to open for screen readers to explain, that a section/panel can be opened. Is that clear enough? Is there something you would like to have changed in the latest patch in terms of a11c?

Many things :) I think the Customizer would need a complete accessibility review and that can't be done by a single person, would need a team effort. It's not a matter of just adding come screen-reader-text, it's about semantics and interaction with assistive technologies.
The h3 headings here are used also as UI controls. Headings should be used just for informative purposes and to give structure to the document, not as UI controls. For interaction, HTML already provides natively keyboard accessible elements (buttons). ​http://www.456bereastreet.com/archive/201302/making_elements_keyboard_focusable_and_clickable/

That said, what can we do without rebuilding all the markup? I'd probably consider to add role=button to the headings. For the ones that open a panel, maybe add also aria-expanded=false. This way, screen readers would announce, e.g.:
Header Image button collapsed
no need to add screen-reader-text, it's a button, it's collapsed, so users would already know that activating them, something will open. For the headings that "close" a panel or go back, I wouldn't use aria-expanded and use some screen-reader-text to make screen readers announce, e.g.:
Customizing Header Image Activate to go back button

Using role=button would also require to attach a keyboard event to the headings in order to mimic a real button, since buttons can be activated with both Enter and the Space bar.

About the sliding panels, please consider the invisible panels are just "out of view" but still focusable and you can tab to them and activate their controls even if you can't see them. I would recommend to have a look at the Press This sliding panels where we tried to take care of this issue and ask @azaozz and @michaelarestad about the implementation details.

[celloexpressions]

We should probably do a new ticket with a full audit of accessibility in the Customizer once this lands then. That way we can identify all of the issues and fix them more easily without wading through an already large patch that is holding up some critical things we're trying to get into this release. As far as I can tell we don't have any regressions in the current patch, and actually have some net improvements. I'm fine with committing to fixing such a ticket in 4.3, but timing-wise it's something we need to work on later in the release. That would also allow time for an extensive review of overall accessibility as well as accessibility in Menu Customizer in the meantime. We simply can't try to fix everything in one ticket or one patch.

@afercia do you think you could open a new ticket for a broad Customizer accessibility audit, and start looking at what testing/review resources are looking like it terms of being able to start putting together that more detailed feedback?

[dovyp]

#32492 was marked as a duplicate.

[afercia]

Replying to celloexpressions:

@afercia do you think you could open a new ticket for a broad Customizer accessibility audit, and start looking at what testing/review resources are looking like it terms of being able to start putting together that more detailed feedback?

Sure, will do :) doubt we can do something for 4.3 though, we're a small team with limited resources.

[dovyp]

Highlight colors are great, but you should make the admin theme colors come through, just to keep it in line with the rest of the WP Admin UI.

[valendesigns]

@dovyp we can certainly do a pass on it for color schemes once it lands. If we try to do that in this patch things would only be that much more complicated and hold up any hope for a merge.

@celloexpressions I'll pick up where you left off and get this patch sorted. It needs to land this week so I'll get right on it.

@afercia If you see anything that can be done that is simple and makes it better than it currently is that's a win in my book. There is so much room for improvement here that any little thing you discover and we can quickly fix is useful. Though we should do a comprehensive review in 4.4 a basic review to get the low hanging fruit in 4.3 will make the larger review a little less, well large. Don't stress over it but if you see obvious stuff please let us know. Have you created a tracking ticket for this yet?

I'll read over the comments and do my best to decipher what's left here, the prolific use of the quote feature isn't going to help me figure it out. Might I suggest we limit our quoting a bit in the future.

[dovyp]

@valendesign I could easily do the SCSS for that if you wish. I've already done it before with Redux, so it would be so very painless...

[ocean90]

Replying to afercia:

Many things :) I think the Customizer would need a complete accessibility review and that can't be done by a single person, would need a team effort.

My question was specific to the patch here to prevent regressions with the change.

[DrewAPicture]

#32492 was marked as a duplicate.

[dovyp]

Admin-theme colors for new hover styles. Global WP SASS variables.

[dovyp]

Added admin theme colors into the _admin.scss files, and added the admin style body class to the customizer.

[dovyp]

Fixed ghost paths. Works now.

[afercia]

Replying to ocean90:

My question was specific to the patch here to prevent regressions with the change.

Would be nice to don't use <span> or other non-semantic elements for UI controls, see #comment:35. About the text suggested for $title Press return or enter to open it's not clear the difference between "return" and "enter" other than the difference in US and UK keyboard layouts. As a non native English speaker that doesn't make sense for me and it would be translated with the same term "Invio".

[valendesigns]

I believe the remaining critical concerns have been address. This ticket is holding things up, so hopefully this will get us there. I will do visrec tomorrow, but I have to call it a day.

• Description are now #555
• Added translator comment to output_widget_control_templates and merged the string
• Fixed hidden widget region
• Added section arrow to mimic panels, and section back button now has proper keyboard support
• Used the button element instead of span for UI controls
• Fixed a JS error thrown by this.currentSidebarControl
• iOS is not perfect but it's much improved, the only issue I see is when you return to the main panel there is a tiny 10px portion of the sub-sections content that you can see briefly to the right on an iPhone
• Fixed an issue where the theme change button was no longer actionable once selected

Known Issues

• Panel & Section transitions are not the same. I feel Section transitions have less oddities compared to Panels and are currently in good shape.
• Admin Color Schemes
• Potentially look at changing the Panel hover/active state arrow

[ocean90]

31336.10.diff​

• iOS: After a theme switch the UI was broken when tapping a control to open, see ​https://cloudup.com/cqFwZ4X_Sox. This happens only in the simulator with an iPhone 6+. Can't reproduce it on a real iPhone 5.
• iOS: The deep-link for the theme switcher (front end in toolbar) produces the same result as above. (iPhone 5)
• The translator comment needs to be added to src/wp-includes/class-wp-customize-section.php:317 as well.
• The arrow for a panel still has the background color which should be removed, see comment:54.

[valendesigns]

@ocean90 Can you explain what you mean by deep-link?

[ocean90]

Replying to valendesigns:

@ocean90 Can you explain what you mean by deep-link?

See ​http://make.wordpress.org/core/2014/10/27/toward-a-complete-javascript-api-for-the-customizer/#focusing.

We have one for themes on the front end in the toolbar.

[designsimply]

iOS: After a theme switch the UI was broken when tapping a control to open, see ​https://cloudup.com/cqFwZ4X_Sox. This happens only in the simulator with an iPhone 6+. Can't reproduce it on a real iPhone 5.

Tested and confirmed with WP 4.3-alpha-32280-src and 31336.10.diff on Safari iOS 8.3 on iPhone 6. Steps to reproduce:

1. Open the customizer on iPhone 6
2. Try opening various panels
3. Tap the "Change" button and preview any theme
4. Try opening various panels again

Result: after previewing a theme, the panels get stuck halfway open. ​1m35s

iOS: The deep-link for the theme switcher (front end in toolbar) produces the same result as above.

Steps to reproduce:

1. Log in to your WP install and open the home page on an iPhone 6
2. Click the first icon on the left in the toolbar
3. Click the "Theme" link

Result: panel is stuck partially open. ​36s

[valendesigns]

@ocean90 I've spent a lot of hours trying to figure out these iOS bugs only to remove the patch and find out it already existed. It's not being introduced by this patch. This should be its own ticket. Can we move forward without fixing iOS right this moment? I can create a patch to fix the remaining two UI issues. What are your thoughts?

[celloexpressions]

Replying to valendesigns:

@ocean90 I've spent a lot of hours trying to figure out these iOS bugs only to remove the patch and find out it already existed. It's not being introduced by this patch. This should be its own ticket. Can we move forward without fixing iOS right this moment? I can create a patch to fix the remaining two UI issues. What are your thoughts?

It doesn't surprise me that the iOS issues were existing - this ticket doesn't touch the themes panel animations so it wouldn't logically be caused by something new. @valendesigns please prepare a finalized patch that addresses all other issues and check it for regressions. @ocean90 please do a final review and commit as soon as possible, at worst within the next 24 hours.

This ticket is (still) in the critical path of several dependencies for Menu Customizer, we don't have time to nitpick every last issue to death right now. Once an initial pass is committed, as I said earlier, it will be much easier to identify and address smaller issues with the implementation without causing regressions in other parts of the patch.

[valendesigns]

@ocean90 Do you want the blue hover removed or turned into the darker blue for the panel arrow?

[valendesigns]

Patch has been updated and is now ready for testing & hopefully commit.

[celloexpressions]

Confirmed that 31336.11.diff​ is ready to go. We're queuing up #30737 to go right after this, planned for tomorrow, which will resolve the critical and urgent Menu Customizer dependencies.

After a first pass commit we can fix any additional issues that come up. The only thing I noticed is a potential further related enhancement of the existing keyboard nav to further improve the emphasis on open sections.

[westonruter]

Resolved merged conflicts between #30737 and #31336: ​https://github.com/xwp/wordpress-develop/pull/89

[westonruter]

I've resolved the merge conflicts between this and #30737, in this patch (and pull request): 30737-and-31336.diff​

Needs testing together.

[ocean90]

Replying to valendesigns:

@ocean90 I've spent a lot of hours trying to figure out these iOS bugs only to remove the patch and find out it already existed.

That's true for the issue with the Themes deep-link but not for the issue after a theme switch (​https://cloudup.com/cEIMTACymAN).

[celloexpressions]

The iOS issue is clearly not something that can be easily debugged or fixed with CSS or JS, as it's demonstrated to work before a theme switch. The only other thing I'd test is whether going directly to a preview URL works; if it does, iOS is just doing some weird caching or something that causes these issues when the Customizer reloads with a different theme query arg. Nothing is different in the theme-previewing mode in the Customizer at the UI level, so there's no logical reason anything at all like this could be happening.

It's not realistic to continue holding up everything here for one device that not everyone has the ability to test with, that's not cooperating at this stage, especially since whatever is the fix there will likely be mostly unrelated to the changing code in the rest of this ticket.

[helen]

We spent a VERY long time chasing down iOS issues with the theme switcher at the end of 4.2, see [32103] for #31794. My suspicion is that animations are still the issue here.

[ocean90]

In 32649:

Customizer: Replace accordion behavior of sections with a slide-in navigation.

This allows users to focus on the contents of the active section more easily and separating the navigation from the content/controls in the Customizer.

props valendesigns, celloexpressions.
see #31336.

[ocean90]

Replying to ocean90:

Replying to valendesigns:

@ocean90 I've spent a lot of hours trying to figure out these iOS bugs only to remove the patch and find out it already existed.

That's true for the issue with the Themes deep-link but not for the issue after a theme switch (​https://cloudup.com/cEIMTACymAN).

That's fixed in [32649].

[ocean90]

Replying to dovyp:

Added admin theme colors into the _admin.scss files, and added the admin style body class to the customizer.

That should be on it's own ticket. But looking at ​https://wordpress.slack.com/archives/core-customize/p1432589265000842 and this seems to be a wontfix. I think we should also revert that blue on hover since the Customizer isn't really "admin".

[helen]

Replying to ocean90:

I think we should also revert that blue on hover since the Customizer isn't really "admin".

The blue on hover is quite distracting. The back icon absolutely must not be blue on hover/focus, as focus is put there automatically and draws your eye there as though it's meant to be the primary action when it is not.

[westonruter]

QUnit tests are broken:

Running "qunit:files" (qunit) task
Testing tests/qunit/compiled.html ....................................OK
Testing tests/qunit/index.html .........................................................................................F.............................
>> Dynamically-created Customizer Section Model - Section instance is expanded after calling .expand()
>> Message: Died on test #1     at file:///.../wordpress-develop/tests/qunit/vendor/qunit.js:263
>>     at file:///.../wordpress-develop/tests/qunit/vendor/sinon-qunit.js:60
>>     at file:///.../wordpress-develop/tests/qunit/wp-admin/js/customize-controls.js:74
>>     at file:///.../wordpress-develop/tests/qunit/wp-admin/js/customize-controls.js:179
>>     at file:///.../wordpress-develop/src/wp-includes/js/jquery/jquery.js:3
>>     at file:///.../wordpress-develop/src/wp-includes/js/jquery/jquery.js:3: 'undefined' is not an object (evaluating 'content.offset().top')
>> Actual: null
>> Expected: undefined
>> TypeError: 'undefined' is not an object (evaluating 'content.offset().top')

Warning: 1/280 assertions failed (1715ms) Use --force to continue.

[westonruter]

I've fixed the QUnit tests in the latest patches on #30737. The problem was that the fixtures had the old templates and they needed to be updated.

[celloexpressions]

To avoid keyboard accessibility issues when sections are opened programatically, we need to move the tabindex and focusing parts of this code from section - attachEvents() into onChangeExpanded:

if ( section.expanded() ) {
	section.collapse();
	backBtn.attr( 'tabindex', '-1' );
	sectionTitle.attr( 'tabindex', '0' );
	sectionTitle.focus();
} else {
	section.expand();
	sectionTitle.attr( 'tabindex', '-1' );
	backBtn.attr( 'tabindex', '0' );
	backBtn.focus();
}

Currently can be seen in Menu Customizer when adding a new menu.

[melchoyce]

Replying to helen:

Replying to ocean90:

I think we should also revert that blue on hover since the Customizer isn't really "admin".

The blue on hover is quite distracting. The back icon absolutely must not be blue on hover/focus, as focus is put there automatically and draws your eye there as though it's meant to be the primary action when it is not.

Totally agree — just encountered the blue hovers and they were incredibly jarring. The blue seems inappropriate in this context. In general a blue background means "this is a primary action," and shouldn't be used as a hover effect. We should stick with the grey here.

[celloexpressions]

Replying to melchoyce:

Totally agree — just encountered the blue hovers and they were incredibly jarring. The blue seems inappropriate in this context. In general a blue background means "this is a primary action," and shouldn't be used as a hover effect. We should stick with the grey here.

This is exactly the same usage of the blue/accent color as is found in the admin menu in every color scheme except for default (where it's still used on the active item). Used for hover on a navigational element.

We can change it to the gray, but would need to ensure that there is adequate color contrast for that style AND add another change besides the color to indicate focus. Currently there is color inversion of text/background colors, which is sufficient, but without inversion I think we need something more than a color change here.

[melchoyce]

Replying to celloexpressions:

Replying to melchoyce:

Totally agree — just encountered the blue hovers and they were incredibly jarring. The blue seems inappropriate in this context. In general a blue background means "this is a primary action," and shouldn't be used as a hover effect. We should stick with the grey here.

This is exactly the same usage of the blue/accent color as is found in the admin menu in every color scheme except for default (where it's still used on the active item). Used for hover on a navigational element.

That's the thing, though — the Customizer isn't the admin bar. It's a tool. We made that determination back in 3.8, when we had initially styled the customizer to match the admin bar before realizing that it just didn't work, because it wasn't the same thing. I forget which, but one of the lead developers made a very compelling argument that the Customizer is more like the widgets or menus UI, which have a more neutral design because they are tools. Now that we have widgets and menus in the customizer, this almost reinforces that.

We can change it to the gray, but would need to ensure that there is adequate color contrast for that style AND add another change besides the color to indicate focus. Currently there is color inversion of text/background colors, which is sufficient, but without inversion I think we need something more than a color change here.

Cool, let's do it. We can use those contrast and focus enhancements to improve other parts of the admin UI as well, so it's a win-win.

[melchoyce]

Replying to ocean90:

Replying to dovyp:

Added admin theme colors into the _admin.scss files, and added the admin style body class to the customizer.

That should be on it's own ticket. But looking at ​https://wordpress.slack.com/archives/core-customize/p1432589265000842 and this seems to be a wontfix. I think we should also revert that blue on hover since the Customizer isn't really "admin".

Agreed that it would be a "wontfix." Color schemes are intentionally excluded from the Customizer.

[celloexpressions]

The other issue here though is that we're quickly reverting to the pre-MP6 problem of having 50 shades of gray in the Customizer, especially if we have to re-introduce gray hover/focus styles. We should probably move this discussion to #29158 and reopen it, handling finding something other than the blue to use there as well as addressing the focus styling. This ticket is focused more on the physical separation of navigation from tools/content, and while we've made a lot of progress with helping to address the related design issues, it sounds like the current solution of introducing the blue isn't working.

[dovyp]

Not sure why we're removing admin themes from the customizer. After all, the save button still changes colors.

I think the customizer should reflect the rest of the WordPress admin...

[melchoyce]

Replying to dovyp:

Not sure why we're removing admin themes from the customizer. After all, the save button still changes colors.

I think the customizer should reflect the rest of the WordPress admin...

It does. For example, look at the menus and widgets screens. The tool UIs remain grey and white, but the highlight colors (checkboxes, buttons, etc.) change along with the color scheme. It's the same for the customizer.

[iammattthomas]

Replying to celloexpressions:

The other issue here though is that we're quickly reverting to the pre-MP6 problem of having 50 shades of gray in the Customizer, especially if we have to re-introduce gray hover/focus styles.

FWIW, the problem we sought to address in MP6 wasn't specifically the fact that there was a lot of gray, but that colors weren't being used in a consistent, considered way. I think 50 shades might be lowballing it a little bit. :) The lesson to take away there isn't that there was too much gray in the admin, but that the colors being used weren't being used with any kind of real unifying logic behind them.

I agree that the blue hover state is jarring—also I'd note that using the same color for an active state and a hover/focus state can cause weirdness like this: ​https://cloudup.com/iKZ1qSkyt83

I haven't been too involved in these discussions so this is just me speaking for myself here, but I'd endeavor to make the Customizer as neutral as possible, limiting the use of color to primary actions, so it takes as little attention as possible away from the star of the show, which is the preview of your site.

[dovyp]

Replying to melchoyce:

Replying to dovyp:

Not sure why we're removing admin themes from the customizer. After all, the save button still changes colors.

I think the customizer should reflect the rest of the WordPress admin...

It does. For example, look at the menus and widgets screens. The tool UIs remain grey and white, but the highlight colors (checkboxes, buttons, etc.) change along with the color scheme. It's the same for the customizer.

I just thought the hover colors were nice and tied in the admin color schemes is all ;)

[westonruter]

From ​https://github.com/xwp/wordpress-develop/pull/91

[westonruter]

I found a couple regressions since this was introduced:

• The completeCallback is not always called when section.onChangeExpanded() fires.
• When a section becomes inactive (active state goes to `false) and it is currently expanded, the Customizer panel then becomes blank as the section is hidden; it needs to collapse the section first before hiding the element.

I have fixes in customize-controls.js.regressions.diff​ which is part of a ​PR I have open for work being done on Menu Customizer.

[westonruter]

In 32743:

Fix regressions from [32649] wrt Customizer expanded and active state changes for sections.

The args.completeCallback was not always called when onChangeExpanded() was called. And when a section became inactive (active state goes to false) and it was currently expanded, the Customizer panel would then becomes blank as the section was hidden; it needed to collapse() the section first before hiding the element.

See #31336.

[helen]

Can we get a quick recap of what's left to do here? The blue hovers still need to be removed, just like they had to be in 4.0 :)

[celloexpressions]

Replying to helen:

Can we get a quick recap of what's left to do here? The blue hovers still need to be removed, just like they had to be in 4.0 :)

Remaining known issues for this ticket are mostly accessibility related:

• Move tabindex/focusing code from attachEvents to onChangeExpanded, per comment 99
• Disable tabindex on non-visible elements (other section headings when in a section)

We should definitely focus discussion of a replacement for the blue on #29158 instead of here since that ticket is specifically for dealing with it while this is focused more on the UX changes. Also, in case it wasn't clear, the attempt here was to try the blue again now that we have distinct navigation vs. functional elements, so it was informed by rather than blatantly disregarding all of the things we tried in 4.0 :) I think the solution there probably just needs to be a non-color focus indicator for section titles & back buttons, and finding the right shade of gray. Would really like to avoid something that feels too heavy/dark or gets too easily washed out, and we have to address the new paradigm of white for interactive elements and gray for background in the Customizer, figuring out how another gray should logically work into the mix. Maybe a slight blue tint?

[afercia]

Replying to celloexpressions:

• Disable tabindex on non-visible elements (other section headings when in a section)

Screen readers offer several ways to navigate trough web pages, tabbing is just one of them. With arrows you can read sequentially any content, not just the focusable elements. There are key strokes to jump through any kind of elements for example in NVDA press "h" to navigate through headings of any level.

To clearly understand what happens, please refer to the screenshot below where I'm just pressing "h". You can see that after the end of the visible panel content it starts to read out the off-screen panels content.
Using tabindex=-1 won't be sufficient here. If you want that content to be hidden from all users, including assistive technologies, then you should really hide it.

See also my previous comment and the Customizer accessibility audit ticket. I'd still recommend to have a look at what was done in Press This. It's already done, maybe abstract a bit that method and just use that?

Also, thinking at maintenance in the long run: why there should be two different implementations of the same thing? What is the best way to build a sliding panels animation? Ideally, there should be just one implementation, available for all the components/tools in WordPress.

[ocean90]

There is an issue with the animation/section width in IE8, see ​https://github.com/voldemortensen/menu-customizer/issues/119#issue-88537447.

[celloexpressions]

Keep forgetting to mention this, but we need to fix the bottom margin on .customize-section-title. It should be set at 15px here for consistency accross all sections regardless of the control that appears at the top (15px matches the space below the first item on the main panel and elsewhere, such as the themes section heading). Note that we should update the menu name controls to have a bottom margin of 15px also, which appears to have been changed to 12px on merge.

[ocean90]

In 32821:

Customizer: Replace usage of calc() with box-sizing: border-box.

IE8 doesn't support calc().

props afercia.
see #31336.
fixes #32664.

[ocean90]

In 32823:

Customizer: Revert the blue on hover color which was introduced in [32649].

Blue is meant to be the primary action which isn't the case in this context. Colors need to be revised in #29158.

see #31336.

[samuelsidler]

@celloexpressions: Where are you on a patch for the issues in comment:114 (and follow up in 115)?

[celloexpressions]

Fix accessibility: focus and tweak tabindex in the proper place, properly hide hidden elements. Also fixes scrollbars.

[celloexpressions]

31336.follow-up.diff​ should finish off this ticket. It does the following:

• Move tabindex/focus code into onChangeExpanded so that it works for cases where expand() is called directly.
• Use visibility: hidden to hide hidden elements from keyboard focus and screen readers.
• The visibility fix also fixes the really strange scrollbar issues that this ticket introduced (they were based on the main panel, not the section you were viewing).

Should be ready for commit, but should be confirmed by at least one other person first. Further accessibility improvements will be made in the audit ticket, this is just to resolve the regressions here.

[helen]

In 33045:

Customizer: Build flips the panel arrow for RTL on our behalf.

see #31336.

[ocean90]

In 33069:

Customizer: Accessibility enhancements.

• Move tabindex/focus code into onChangeExpanded so that it works for cases where expand() is called directly.
• Use visibility: hidden to hide hidden elements from keyboard focus and screen readers.

props celloexpressions.
fixes #31336.

[ocean90]

In 33599:

Customizer: Remove obsolete .control-panel-back and .customize-overlay-close buttons.

props afercia, ocean90.
see #31336.
fixes #33229.