[wp-trac] [WordPress Trac] #22058: Improve custom background properties UI

[WordPress Trac]

#22058: Improve custom background properties UI
-------------------------------------+-------------------------------------
 Reporter:  grapplerulrich           |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Customize                |     Version:  3.4.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch ui-feedback    |     Focuses:  ui, accessibility,
  needs-testing has-screenshots      |  administration
-------------------------------------+-------------------------------------

Comment (by afercia):

 I will leave more in-depth design considerations to the UI/design team,
 just wanted to say that I feel this would add a bit too clutter to the UI
 maybe for little benefit. Comparing the current UI and the proposed one
 side by side, the latter gives me the impression of a wall of ''at-first-
 sight-pretty-obscure'' icons vs the simplicity of the former:

 [[Image(https://cldup.com/gAuSSGy4qe.png)]]


 About accessibility and semantics, radio buttons would be the best option
 because that's what they are meant for: a single choice between related
 options. By the way, they would need to be grouped in a fieldset with a
 legend. About the importance of fieldsets and legends I'd recommend this
 post by Leonie Watson, goes directly to the point with simple examples:
 https://accessibility.blog.gov.uk/2016/07/22/using-the-fieldset-and-
 legend-elements/

 Worth mentioning there are various CSS techniques to hide the radio
 buttons and use their label elements to provide a different visual, I
 think Press This uses one of them.

 Please consider every time there's the intent of changing and transforming
 native controls, then there's the need to replicate all their native
 functionalities otherwise the native level of accessibility will be
 decreased. I understand the point to ''make the options more visual,
 reducing the use of technical terminology'' but this shouldn't happen at
 the cost of reduced accessibility. My general recommendation would be to
 keep the current radio buttons and just improve the labels wording.

 Additional considerations:
 - icon-only controls are tricky and ideally
 [https://www.nngroup.com/articles/icon-usability/ icons would need a text
 label]
 - whether they're going to be radio buttons or buttons, they need to be
 grouped in fieldsets with a legend
 - proper fieldsets and legends would also allow to simplify the labels: no
 need to repeat "Set Tile Background to...", "Set Tile Background to...",
 "Set Tile Background to..." etc. for each option
 - selected state: if radio buttons, that's natively announced by assistive
 technologies but if `<buttons>` then they would need an `aria-pressed`
 attribute, as done for the "device preview" buttons
 - initial state: not clear why some properties have a clear indication of
 the initial state and others don't, see also the `false` value set for
 these properties in the screenshot below
 - technical terminology: completely agree to avoid it, I'd also add that
 some terms are difficult to translate, for example "tile" and maybe the
 wording should just explain users what a control does with the simplest
 possible wording

 [[Image(https://cldup.com/KIY1_IFcf2.png)]]

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