[wp-trac] [WordPress Trac] #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior

[WordPress Trac]

#31336: Customizer: separate navigation from options UI for better UX by removing
accordion behavior
--------------------------+------------------------------------------------
 Reporter:                |       Owner:  ocean90
  celloexpressions        |      Status:  assigned
     Type:  enhancement   |   Milestone:  4.3
 Priority:  normal        |     Version:  4.0
Component:  Customize     |  Resolution:
 Severity:  normal        |     Focuses:  ui, accessibility, administration
 Keywords:  has-patch     |
--------------------------+------------------------------------------------

Comment (by ocean90):

 Replying to [comment:51 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

 [[BR]]

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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31336#comment:53>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform