Improve "Visibility" and "Publish" labels in Post Settings

[afercia]

Example:

The "Public" and "Immediately" controls in this example don't reflect the available action, instead they reflect the current state of the underlying option. I'd say this is a bit confusing also visually. Additionally, when read out of context, users won't have a clue what, for example, "Immediately" relates to.

UI controls should always be meaningful. Looking at the controls in the current WordPress Publish box, the state and the action are separated and the "Edit" controls have an expanded screen-reader-text. Theres a good reason for that. The current design implements what I'd consider without doubts an accessibility regression. Note: this could be implemented also with aria-label.

[samikeijonen]

In accessibility team bug scrub we talked about this issue. Option 1 and 2 were clear winners, and ideally Option 2.

• Everything should be clickable control, not just icon.
• If using the icon, it should be hidden from AT.
• Ideally wording with “Edit”. In German that would be "Bearbeiten", in Finnish "Muokkaa", in French "Modifier". There is a small risk getting the words in 2 lines but I don't think that would be an issue with proposed design.

@afercia What does this mean:

The text representing the state must not be included within the button tough

Does that mean word "Public"?

[afercia]

@samikeijonen I meant the button element should contain only the text describing the available action "Edit ..." while the "state text" should be outside of the button. Pseudo code:

<button aria-describedby="publish-date-state">Edit publish date</button>
<p id="publish-date-state">October 9, 2018 7:27 PM</p>

[sarahmonster]

This pattern came up as being problematic when I was working on #12788 and #12048. It would be great to see if we could land on a good fix for it. Let’s see if we can revisit this issue with the aim of finding a solution that’s better than what we currently have for all users, even if that means we may need to forsake the ideal solution right now.

From discussion here, it seems that option 2 above is best from an accessibility perspective, and option 1 is best from a usability & pattern extensibility perspective. Let’s try riffing on these ideas a bit to see if we can’t come up with an approach that marries the advantages of both.

In an attempt to show underlying semantic structure, I’m going to try to reflect how I'd see the underlying markup for each option shaking out, but obviously this is going to be up to an implementation detail and there's some wiggle room here.

Current state of play

<span>Status</span>
<button>Pending Review</button>

Pros:

• Visually quite simple & uncluttered.
• Allows for variable labelling ("Scheduled for" rather than "Publish")

Cons:

• Difficult to scan visually to quickly absorb information.
• Popovers aren't ideal and feel awkward.
• Pattern used is similar to the publishing flow panels, but just different enough to cause conflict.
• Doesn't work well for users of assistive technology.
• Related elements lack proximity, making them feel less connected conceptually.
• Lack of any real hierarchy makes it hard to tell which is the most important information. (Ideally, this would be the variable state part, like “public” or “pending review”.)

Option A

<button>
<span>Status</span>
</button>
<span>Pending Review</span>

Cons:

• Carets start to get visually lost in amongst one another.
• Label acts as a button, could be suboptimal for variable labels.
• Small-caps can be difficult for some users.

Pros:

• Follows existing patterns for expanding and collapsing panels.
• Gets rid of the popover behaviour.
• Very similar to this same section of the pre-publish panel. (If we went this route, making them identical would be advisable.)
• Strong typographic hierarchy, easy to scan.
• Extensibile pattern.

Option B

<span>Status</span>
<span>Pending Review</span>
<button>Edit <span>Status</span></button>

Pros:

• Clearly separates the state from the editing action.
• Allows for variable labelling to provide additional context.
• Easy to scan.
• Clear hierarchy.

Cons:

• Edit buttons feel visually clunky and distract focus.
• Limited extensibility.
• Text may need to be hidden via CSS.
• Button tap target is tiny; we’d need hack it so the whole row would act as a button.

Option C

<span>Status</span>
<span>Pending Review</span>
<button>Edit Status</button>

Pros:

• Clearly separates the state from the editing action.
• Allows for variable labelling to provide additional context.
• Clear hierarchy.
• Seems closest to the ideal semantic structure.

Cons:

• Edit buttons are clunkier still.
• Limited extensibility.
• Using an icon and text allows for a more explicit button label.
• Visually a bit Frankensteinish; probably requires more padding & vertical space in order to work well.

Option D

<button>Edit <span>Status</span></button>
<span>Pending Review</span>

Pros:

• Clear hierarchy.
• Simpler semantic structure.
• Styling the non-variable “edit” text differently allows they eye to ignore it visually, preserving the ability to scan unique labels.
• Strong left alignment makes text easier to scan and parse.

Cons:

• Positioning of [edit] may require some thinking.
• Variable labelling leads to a less-than-optimal button label (“Edit scheduled for”?)

[afercia]

@sarahmonster thanks for your explorations. Amongst the options, D is the one that's closer to clear semantics, better accessibility (and I'd like to say better usability, as usability is part of accessibility) 🙂

But...

The "labels" shouldn't change dynamically. I'd like to clarify terminology first: as accessibility specialist we refer to a "label" as to what gives a control its accessible name, which is the name browsers expose to assistive technologies. In this case, the label is the button text. For input fields, the label is the actual <label> element, or an aria-label, etc. It's likely designers use the term "label" in a different way, as in some visible text.

So when I said above the label shouldn't change, I'm referring to the button text. That gives the controls their name and identifies the available action.

Users who learn there's a control with name "xyz" won't have a clue the control will change its name and at some point will be "abc". For them "xyz" is just disappeared and they would be forced to explore around and figure out what happened. Far from ideal.

For this reason I'd like to stress the buttons text shouldn't change. It needs to clearly identify the available action once and forever. 🙂 In an attempt for clarification, I'd like to attach a couple quick screenshots to illustrate what is the underlying HTML in the Classic Editor publish box. It's important to note this is actually what user perceive when they use the publish box:

• the current value/state is completely separated by the action
• the buttons (they're actually links that behave like buttons) clearly identify the available action and their text doesn't change

Of course things can be rearranged and improved but I'd warn that any deviation from this clear separation between value/state and action would be a regression in terms of accessibility compared to the Classic Editor.

To my understanding, option D is very close except that the publish date button text shouldn't change.

I'd also suggest to remove the parentheses and the uppercase text, as they impact the way screen readers read out text.

If the markup was something like the following, I'm pretty sure we could use some hidden text or aria-describedby to further improve the association between buttons and values. Example:

<button>Edit Status</button>
Pending Review 

<button>Edit Visibility</button>
Public

<button>Edit Publish Date</button>
Scheduled for 13:00 3 January 2019

Would something like the above work for visual purposes?

[bemdesign-er]

I agree with afercia - please do not have control's text/value/labeling change to indicate state. That can cause all sorts of user confusion!

[afercia]

See also related considerations on https://github.com/WordPress/gutenberg/pull/15381#issuecomment-488688080

[sarahmonster]

Based on the comments above, it seems like Option C might be our best bet to clarify these settings for the majority of users. Here's a quick comparison of our options as per C and D above:

<button>Edit Status</button>
Pending Review 

<button>Edit Visibility</button>
Public

<button>Edit Publish Date</button>
Scheduled for 13:00 3 January 2019

Here, D is a less cluttered solution, but may not provide enough information to be easily used by all users:

• Having each label start with "Edit" makes it hard to quickly scan and differentiate the different sections.
• We aren't able to clarify the publish date settings by changing the label the way we could with the classic editor, which has been a source of confusion for users.
• There's no real label for these controls beyond the button, which is phrased as an action.
• It seems rather unexpected that the button control precedes the state itself.

<span>Status</span>
Pending Review 
<button>Edit Status</button>

<span>Visibilty</span>
Public
<button>Edit Visibility</button>

<span>Scheduled for</span>
Scheduled for 13:00 3 January 2019
<button>Edit Publish Date</button>

C introduces more visual clutter, but seems like a better solution for all users:

• More explicit labelling of controls.
• Predictable order of elements (label, state, control).
• Allows for clarification of publish date, classic-editor style.

Visually, it would need some tweaking to feel usable—it's a bit messy right now—but semantically, would this be a better approach here?

[afercia]

semantically, would this be a better approach here?

@sarahmonster thanks for your explorations, perseverance, and hard work 🙂

Yep I'd say C is good from a semantic perspective and could be further improved with some aria-describedby under the hood. 🎉 I share your same feeling that it would need some visual tweaking, as long as there's visible text for "action + what". Edit Status, Edit Visibility, Edit Publish Date are clear for everyone and I'd say also an improvement compared to the Classic Editor!

[davewhitley]

Thank you for reviving this issue! I appreciate the collaboration going on here.

The two option C's above look similar to a design I, and others proposed earlier in the comment thread, but with some slight text and design tweaks.

It appears the main sticking point in this design is that the pencil icon does not have a visible text label. Also, @afercia, your point on using icon-only buttons throughout this thread is well taken. I agree that it's best to use text as much as possible. Some questions I have:

• Can this pattern be thought of as a combobox? The definition sounds spot on. Comboboxes look like select elements (I know the definition says "textbox") with an arrow icon on the right, correct? What makes that more accessible than the proposed pattern with just a pencil icon?
• Translations could be an issue. Not all of the edit buttons with text (Edit status, Edit visibility, etc.) will have the same width, and cause the button to drop underneath.
• I missed the reasoning on including the "what" in the buttons. Is it possible to just have "Edit"?
• Are there alternative icons that we haven't thought of for "edit" or "change"?
• Is the pencil icon one that can be mostly understood by all, without the need for text (e.g. magnifying glass, caret, cross, etc.)? Can we test that?
• Is this a case where the context is enough to indicate that the element is actionable (context being, a row of similar items with a border separation in a sidebar).
• Should any of these questions be tested in conjunction with this issue?

[afercia]

Briefly:

Can this pattern be thought of as a combobox?

A combobox widget is meant for auto-complete suggestions, not sure how that applies here.

I missed the reasoning on including the "what" in the buttons. Is it possible to just have "Edit"?

Think at speech recognition software users or users with cognitive impairments. "Edit" misses the "what" to properly understand what the control does and be able to voice a proper command.

Translations could be an issue Is the pencil icon one that can be mostly understood by all

I think these two points fall under the "visual tweaking" @sarahmonster already mentioned?

Is this a case where the context is enough to indicate that the element is actionable (context being, a row of similar items with a border separation in a sidebar).

No.

[davewhitley]

A combobox widget is meant for auto-complete suggestions, not sure how that applies here.

Definition:

A combobox is a widget made up of the combination of two distinct elements: 1) a single-line textbox, and 2) an associated pop-up element for helping users set the value of the textbox. The popup may be a listbox, grid, tree, or dialog. Many implementations also include a third optional element -- a graphical button adjacent to the textbox, indicating the availability of the popup.

The pattern being proposed seems very similar to me. A combination of a select and combobox. You interact with an element, a popup is displayed, and then you make a selection.

My point is that a chevron/caret icon is enough to indicate interaction for selects and comboboxes. In theory, wouldn't that be enough for this pattern as well?

[afercia]

@drw158 maybe read the entire definition and reach the point where it clearly explains it's for suggested values and auto-complete? :)

In terms of ARIA, the equivalent of a <select> element is a listbox instead.

The difference being:

• combobox: users can actually type in the input field
• listbox: users can't type, they can only choose one of the predefined options from the list of options

[davewhitley]

I think there's been a bit of miscommunication. My comment above was misleading and it sounded like I was asking if we could use the combobox pattern:

Can this pattern be thought of as a combobox? The definition sounds spot on. Comboboxes look like select elements (I know the definition says "textbox") with an arrow icon on the right, correct? What makes that more accessible than the proposed pattern with just a pencil icon?

I understand that a combobox is comprised of a single-line textbox and users can type into the field. Because of that, I realize that a combobox is not appropriate for the pattern we are designing.

My main question is stated above in my previous comment:

The pattern being proposed seems very similar to me. A combination of a select and combobox. You interact with an element, a popup is displayed, and then you make a selection.

My point is that a chevron/caret icon is enough to indicate interaction for selects and comboboxes. In theory, wouldn't that be enough for this pattern as well?

So to ask the question differently: what makes the proposed pattern less visually accessible than selects and comboboxes? To me, it looks like the proposed pattern could be more visually accessible because the icon is bigger and more descriptive. Note, this is assuming that all the elements are technically accessible and support assistive technologies.

[afercia]

I'm not sure what we're discussing 🙂I don't see specific problems with the current interaction, there are ways to semantically communicate a button opens a popup (e.g. aria-haspopup, aria-expanded).

Icon-only controls are a no-go, for the reasons explained several times in several issues in this project over the last two years. That said, I wouldn't be opposed to a decorative icon in addition to the button text, if that helps to visually clarify these controls purpose.

What we are discussing in this issue is the labelling of the buttons, and I'd recommend to stay focused on the point. Again: these buttons are currently labelled with the underlying option state. Whatever we put it, this is a mistake. Buttons are meant to communicate the available action, not the state. Seems to me this should be a very basic principle of any user interface.

This:

<button>Public</button>
<button>Immediately</button>

doesn't help users in any way. What in the world the button labelled "Immediately" does? Same when it's labelled with the actual date:

<button>Jul 12, 2019 3:56 pm</button>

Why we should force users to explore the surrounding context to actually understand what these buttons do? For example, screen reader users can navigate through form controls and what they perceive is definitely not clear:

I'd say that also visually, users are forced to scan the UI around the buttons to actually understand what "Immediately" and "Public" are meant for.

Ideally, what we'd need here are just button labels that clearly communicate the available action:

<button>Edit Visibility</button>
<button>Edit Publish Date</button>

because that's what these buttons do.

[mapk]

This one is definitely lingering. I'd like to bring it to a close if possible.

Currently, we show the "status & visibility" in the Document Settings... but then we also show these a bit differently in the pre-Publish sidebar. They seem to work better as they're designed in the pre-Publish sidebar and I wonder if we just bring that over to the Document Settings?

Collapsed view

Visibility panel open

Publish panel open

A couple things I haven't included in these mockups are these below. I'm sure we can work them in quite easily though.

[paaljoachim]

NB. I am showing the pages publish flow. Which means there is no Stick to the top of the blog message beside a checkbox as would have been if I had shown the process with a post.

---

Existing Publish Panel: .

Existing Pre Publish Panel: .

---

Click the link to test out a prototype of a possible new Publish Panel layout. https://www.figma.com/proto/UDVQks6ap5E3o8KAF6bpEi/Publish-screen?node-id=9%3A8&scaling=min-zoom

---

.

Animated gif:

I think we should add the Pending review checkbox etc to the Visibility panel. This will likely be the panel that is seen by default when Document panel is selected.

.

. .

The question I sit with after creating the above is... what do I want to see in a Document panel that by default is open? Which needs are most present? Should we have a Status panel that by default is open when clicking Document showing a kind of summary of panels below? A status panel that also uses information from Full Site Editing. That is another issue that perhaps already exists.

[joedolson]

There are a lot of things I like about this. First, it reduces the number of interfaces to deal with by making the pre-publish and post-publish the same, which is definitely a win. Second, there's a clear set of controls for changing status and a separate disclosure that conveys the current status. Because that control follows the same disclosure model used throughout the editor, I feel pretty comfortable with it.

I like that it does away with the repeated 'Edit' controls, and I like that it separates the 'visibility' question from the 'publish time' question - having those grouped together is awkward, in my opinion.

I think it's definitely helpful to all users that the information will be presented in the same way when you set it as it is when you're asked to check it.

It does make sense to me to include 'Pending Review' in the visibility section, I think. I don't know where else it would go.

Overall, I'd be pretty comfortable with this change.

[enriquesanchez]

The Accessibility team discussed this issue and we agreed that utilizing the pre-publish UI for these settings feels like a good next step to try.

[afercia]

I'd tend to agree with @joedolson. Using the disclosure components already used in the pre-publish checks is an improvement. Also, we will get rid of the current "popovers", which have their own keyboard interaction and focus problems.

Specifically to the name of the buttons, which is the main point of this issue, here's a comparison:

Current pattern:

The accessible name of the Publish and Visibility buttons only conveys the underlying setting state, which is a bad pattern for accessibility and usability in general:

Immediately or, for example, 27 May 2020 9:59 pm

Public or Private or Password Protected

New pattern:

The accessible names of the disclosure buttons conveys both the "what" the button refers to and the underlying setting state:

Publish: Immediately or, for example, Publish: 27 May 2020 9:59 pm

Visibility: Public or Visibility: Private or Visibility: Password Protected

Still not ideal, but it's an improvement.

To clarify again why it's not 100% ideal:

• buttons should identify the available action
• in our case, the available action is still not clearly communicated
• buttons must not be used to communicate a state

To make a visual example, I guess no one would ever think to add the state to a button that filters the list of posts e.g.:

• "Filter: Not filtered yet"
• "Filter: filtered by date"

Ideally, the state should be communicated separately. Here's what I would do, in pseudo code:

<button aria-describedby="visibility-description">Edit visibility</button>
<p id="visibility-description">Visibility is set to "Public"</p>

<button aria-describedby="publish-date-description">Edit publish date</button>
<p id="publish-date-description">Publish date is set to "Immediately"</p>

[ZebulanStanphill]

I've created #24024 to improve the situation by splitting the "Status & visibility" panel into smaller, more focused panels.

[paaljoachim]

This issue in regards to "Improving the "Visibility" and "Publish" labels in Post Settings" will be influenced by the work going on in Full Site Editing. Here is a comment I made in the FSE issue: https://github.com/WordPress/gutenberg/issues/20474#issuecomment-658303082

[afercia]

Seems there's finally consensus on the last proposal, see https://github.com/WordPress/gutenberg/issues/470#issuecomment-627628262 and it would be great to consider the adjustments proposed in https://github.com/WordPress/gutenberg/issues/470#issuecomment-635364842.

This issue is waiting to be solved since almost 3 years and a half. It would be great to help it move on 🙂 Milestoning to WordPress 5.6 for visibility.

[ZebulanStanphill]

I've created #25170 to implement accordion summaries that don't mess up the toggle label semantics. If it could be merged alongside #24024, this issue would finally be resolved.

[gwwar]

Hi @ZebulanStanphill are there any updates for this one? We're checking in as part of a triage session in #core-editor

[ZebulanStanphill]

@gwwar

25170 is blocked by a deep design/accessibility conflict. Trying to add a summary to an accordion is tough since the <button> to open the accordion has to be inside the <h_> element, and putting a summary inside the heading is semantically incorrect and confusing for screen readers. But if the summary isn't there, then it's difficult to make it clickable. But if the summary doesn't make sense inside the button, then why have it be clickable in the first place?

I get the feeling that perhaps the very idea of trying to fit a summary into an accordion header is fundamentally flawed. If so, we have to find a different way of displaying the current post visibility/status. Not sure how to proceed there.

24024 is waiting for a review and for #24079 to be merged first... and that PR is also waiting for a review.

[joedolson]

Summary of changes I can see since this was last dealt with:

1) The 'Status and Visibility' panel is now called 'Summary'. 2) The controls to change visibility and status have not changed their visible labels, but have an aria-label with more information: e.g. "Select visibility: Public"; "Change date: Immediately". While I might quibble over the exact wording here, it is better. 3) The alignment of the controls has changed, so they now have better proximity to their current status. 4) Pending Review and other toggle features now use a standard checkbox.

Overall, this has improved; but more importantly, much of the discussion in this issue is now obsolete due to the changes in the underlying system. Perhaps this issue should be closed and the remaining concerns should be opened as new issues? This one is so long and out of date that I'm not sure it's helpful.

Appreciate your thoughts on that, @afercia.

[jordesign]

Overall, this has improved; but more importantly, much of the discussion in this issue is now obsolete due to the changes in the underlying system. Perhaps this issue should be closed and the remaining concerns should be opened as new issues? This one is so long and out of date that I'm not sure it's helpful.

I'd second this opinion. It's also possible/likely that Phase 3 of Gutenberg - covering collaboration and editorial flows will need to address items in this panel - so it would be great to revisit this and open a new issue with the still-relevant details.

@afercia - If you have no objection to revisiting this in a new issue - I'll close it out in a week.

[afercia]

@joedolson @jordesign thanks for the ping. It is true that many things have changed and most of the discussion on this issue is now obsolete. The general principle still stands though: name controls based on what they do, not on the selected value. This seems to be something that designers in this project still struggle to understand and it's still a major accessibility barrier, besides being less-than-ideal design.

I'd like to also mention that now the visible text and the actual accessible name mismatch so that issuing a voice command for speech recognition software will fail.

I'll create a follow-up so and close this one.

For history: examples of the current situation as of July 10th 2023 (6 years after this issue was created):

Visibility button: 
Visible text: Public 
Accessible name: Select visibility: Public

Publish button: 
Visible text: June 26 12:37 pm
Accessible name: Change date: June 26 12:37 pm

or:

Visible text: Immediately
Accessible name: Change date: Immediately

Template button:
Visible text: Single Posts 
Accessible name: Select template: Single Posts 

URL button:
Visible text: localhost:8889/2023/06/a-simple-post/
Accessible name: Change URL: localhost:8889/2023/06/a-simple-post/