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.

[jasmussen]

✨ Another great ticket. I will possibly ping you again as this gets implemented.

[joyously]

It's the Pending Review one that makes no sense to me. (I can't ever tell if those "switches" are on or off, even with a color.)

[afercia]

@joyously right, maybe worth a separate issue. Just noting other similar switch toggles have a visible on/off label in other parts of the proposed UI:

[afercia]

A quick comparison of the switch toggles and some label/controls from the current mockups. Apart from small design details to define, should the switch toggles always have a visible on/off state indicator? (for a11y: yes).

Also, ideally form labels should not contain links (I know that WP currently does that, but it could be improved).

Note: the switch toggles would need some a11y special treatment. It's definitely possible to make them accessible, but I guess this should go in a separate issue.

[afercia]

To clarify, ideally the Visibility and Publish button should just identify what they do (the underlying available action):
"Edit Visibility"
"Edit Publish Date"

The visual presentation of the current settings value should be separated and not be part of the buttons.

[afercia]

To further clarify why this design pattern is far from ideal because control labels containing the setting value or state don't make sense when read out of context:

[afercia]

I'd also like to point out this metabox name is "Status & Visibility" but then when I open it, there's no label or control that refers to a "Status". While this may be implicitly clear for experienced WordPress users, I wonder new users wouldn't have a clue what the "status" references in the metabox name is.

Quick Classic editor / Gutenberg comparison:

[afercia]

About the "Visibility" and "Publish" buttons (which actually are labeled with the value of the options) I'd also recommend to have a look at the testing session by @sinabahram recorded by @joedolson at CSUN 2018, starting form minute 8:00 https://youtu.be/qpzyiL7n__0?t=8m and also published on https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/

Why we can't just label the button that is now "Public" as the Visibility button with its value set to "Public"?

"Publish" is weird to me, it seems like an action but it's just text ...

To me, this just confirms the confusion users experience with these buttons. Again, they go against one fundamental web design principle: UI controls should be labeled with the name of the underlying action, not with the current value of the underlying setting.

[sinabahram]

I do think it is possible to do both. Again, I’ve volunteered to hop on some free calls and devise some solutions to problems like this if interested?

[afercia]

@sinabahram thanks so much. Yep we could try to do both, if there's some consensus from the Gutenberg project leads. In the current WordPress editor, these two bits of information are separated and they use some plain text and a button, for example:

text: Visibility: Public
button: Edit visibility

Not saying that's ideal, it requires a bit of exploration but hopefully it's a bit clearer.

In Gutenberg I'd suggest to try something like:

button: Edit visibility: Public

and

button: Edit publish date: May 2, 2018 3:53 pm

or something along those lines.

I'd greatly appreciate some help on an important issue you've noticed during your testing session: JAWS doesn't read out the value of the editable fields in the post content. I've created a specific GitHub issue for that but haven't found a solution yet (insert disappointed emoji here): #6002
Will ping you on that issue, thanks!

[sinabahram]

There are known best practices for this stuff, just not written up very well. it’s why folks like me spend so much time with various devs on calls, in person, etc. … Happy to do a bit of a brain dump whenever the willingness and availability exists. Problems like this one should take a few moments to solve, no more, as there are ways of doing so that don’t affect the visual UI and maintain the accessibility for AT users. For example, that needs to be a single control, and we could obviously have the button serve that purpose, then throw aria-hidden on the current status. the single control needs to advertise current state and what will happen if its toggled e.g. “changes to private” or whatever.

[folletto]

I've done some brainstorming with @afercia to come up with a solution here... we found one that while doesn't reach the ideal state we'd love to have, it should still be a solid improvement on what is happening now:

This approach works by changing the visual slightly, and attaching a <label for="">Visibility <div>Public</div></label> with the for target being the "Change" button. The outcome is that "Visibility: public" is being spoken instead of the button content.

The benefit of this approach are:

1. Works with screen readers, in a way similar to the other controls (with dropdowns) in the same page
2. It adds a much needed label to the value visualized, providing much needed context.
3. It makes the "Change" action explicit for everyone.
4. Bonus: the label is clickable too, making a larger tappable area useful to both desktop and mobile.

The remaining issues this approach wouldn't solve are that basically might be even better if "Change visibility" was spelled out entirely, instead of relying on aria-expanded to hint at the action.

Yet, should be an improvement.

Thoughts?

[jasmussen]

That seems good! Is there space so visibility v public can stand on one line, or wrap if it needs to for translations?

[folletto]

If it was only for "Visibility" it might have been possible. However, I think it would be odd to have "Visibility" on one line, and "Publish" on two (note: in the mockup I changed only "Visibility"). For symmetry, and also to avoid potential issue with text going too long in translations, I think both should go on two lines.

[anevins12]

Sorry long thread and I apologise in advance if I've misread or duplicated someone's response.
Looking at this from a conformance point of view, are we trying to reach AA? I understand that we should focus on the user experience and real A11y issues, but the W3C have already gone through a lot of the user testing for us and we should be able to say "because this conflicts with the W3C I don't think it'll be a good experience".

So, if we're aiming for WCAG AA compliance, I'm afraid we're not describing the action of buttons or links when using the date (for example) as the textual description.

https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G131

[bemdesign-er]

Labels should clearly articulate what the control does so users can understand what the expectations are for using that control and possible results of their actions by using that control. This is good for both usability and accessibility. Also consider the use case of a screen-reader - does the label clearly tell the user what the control is and what it does?

[folletto]

The latest proposal above (#470 (comment)) will speak:

Visibility: Public, collapsed, button

So it both describes the button ("Visibility" → "Identify the purpose of the interface component.") and the content ("Public"), as well as the state ("collapsed") and the type ("button" → "Check that each label makes the component's purpose clear.").

Any reason why you think it doesn't match the requirement?

[afercia]

Any reason why you think it doesn't match the requirement?

Yes: there's no consensus and no progress yet 😄

[afercia]

Looking again into this, it's a bit more complicated than how it seems for at least two reasons:

• it's not just about Visibility, it's also about "Publish" and having two "Change" button would be confusing for all user and hard to use for speech recognition software users
• when users have no permission to edit, there's no button rendered; there's only a text with the Visibility state, so also the label should be rendered conditionally...

[tofumatt]

@mtias wanted me to check if this is still an issue and what's actionable here.

The issue is still valid because the label for the current state is also a button that opens the visibility settings (for "Public") and a date picker (for "Immediately").

I think the most accessible version of this (and possibly the easiest to implement) is doing what the old WP-Admin did: having the current status and an "edit"/"change" button next to the status to change it.

Alternatively we could label the current links to have an off-screen, for screenreaders, bit of text that contextualised things. The text could be, for the datepicker: <span class="screen-reader>Date to publish:</span> $DATE <span class="screen-reader>(Click to change)</span>

That could work but I think it's a bit more awkward for users and to code. I think putting the change buttons next to the current state would be best, visually using what @folletto mocked up.

[afercia]

Seems there's finally consensus on the last proposal, see #470 (comment) and it would be great to consider the adjustments proposed in #470 (comment).

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/