[wp-trac] [WordPress Trac] #41610: Widgets: Change "close" to "done?"

[WordPress Trac]

#41610: Widgets: Change "close" to "done?"
-------------------------+--------------------------
 Reporter:  melchoyce    |       Owner:  westonruter
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:  4.9
Component:  Widgets      |     Version:
 Severity:  normal       |  Resolution:  fixed
 Keywords:  has-patch    |     Focuses:
-------------------------+--------------------------

Comment (by afercia):

 I'm not sure I fully agree with the solution implemented here. While I
 agree there should be an indication of the saved state, I think the button
 isn't the proper place for that.

 I've recently noticed this new design trend also in other places across
 the admin, and I'd recommend to reconsider it. As I see it, the main issue
 here is that buttons (and other UI controls) that perform an action should
 be exclusively labeled to indicate the available action.

 Instead, with this change (and also in other places in the admin), the
 button label is actually a mix of the available action ''and'' the UI
 state:

 [[Image(https://cldup.com/Qe-yAeIXT7.png)]]

 Mixing these two different information in the same place defeats the
 purpose of properly labeling UI controls and is potentially confusing for
 users, not to mention it's far from ideal for accessibility.

 In other places in the admin things are even more confusing, when the UI
 control label is actually ''the value'' of the underlying option.
 Thinking, for example, at the Publish option in Gutenberg which says
 "Immediately" or uses the publish date. UI controls labels should make
 sense even when read out of context: "Immediately" or "Saved" don't tell
 me anything about what the available action is.

 UI controls that perform an action should be used just to perform actions.
 Not to indicate the underlying state or value. A state indicator is a
 completely different thing from a button (or other UI controls) and should
 be separated from the control.

 I know this is not completely new in WP, I'm commenting here just because
 it's the most recent implementation of this new trend I'm aware of. I'd
 like to see a broader discussion on this issue involving both the design
 and accessibility team.

 As a general consideration, there's no need to reinvent the wheel trying
 to do fancy things. Design should explore new solutions, but always
 respecting the specifications. A button is a button, just that. Please
 respect the elements semantics and use HTML elements for what they're
 intended for.

 Apart from these considerations, disabling the button causes a focus loss,
 one of the worst experiences for keyboard and screen reader users. This
 was mentioned several times: for accessibility, disabling, hiding, or
 removing from the DOM an UI control that currently has focus should be
 avoided. This should be tested for accessibility to evaluate the focus
 loss impact, since browsers are making some progress in this regard and
 they try to keep focus in place when possible. I'll propose some testing
 during the next accessibility meeting.

 Aside: not sure why both the `input` and `change` events are used; `input`
 should be enough, unless I'm missing something.

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