Gutenberg: 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): https://github.com/WordPress/gutenberg/issues/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 (https://github.com/WordPress/gutenberg/issues/470#issuecomment-387169279) 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]

We should consider not only screen readers. Ideally, a label should be visible and communicate the action. For example, speech recognition software users need to know the accessible name of a control to voice a command. The accessible name should match the visible label or at least start with it. See https://www.w3.org/TR/WCAG21/#label-in-name

[tofumatt]

Yes, that's why my first suggestion was to replicate the classic editor implementation; the button to edit is visible, contains text that says what it does, and is distinct from the status:

Visibility: Public (<button>Change <span class="screen-reader">visibility</span></button>)

That would work, right?

[GlennMartin1]

Hope it's not out of place to mention this here:

See https://github.com/WordPress/gutenberg/issues/6604 about a mobile issue of not able to change Visibility settings on mobile.

(the related issue of changing dates on mobile is resolved).

[afercia]

That would work, right?

Yes for screen reader users, no for sighted users with accessibility need. For example with 2 "Change" buttons that look the same, what command speech recognition software user should voice? The command "Click Change" wouldn't help to directly activate the buttons. Also, users with visual impairments of cognitive impairments would be potentially confused by two buttons that say the same thing. The best option would be using a visible, meaningful buttons text:

<button>Change visibility</button>
<button>Change date</button>

Or "Edit" instead of "Change". I do realize the space is limited, but that's a design issue. Design should adapt around content, not vice-versa.

[afercia]

Also, it's not the only case of UI controls labelled with the underlying state instead of their action 🙂

[tofumatt]

Indeed, but I'm just trying to start someplace 😄 I think these are the only ones in the document sidebar. 😅

I am for the full text visually from an accessibility standpoint, but there's barely space for it in English and I worry about translations. Maybe with @folletto's mockup we could try that. I'd be for seeing someone give it a go, so we'd have:

but "Change" would be "Change Visibility" (or edit, or whatever we pick 😄). That'd work for me for accessibility and design unless I'm missing something.

Bonus: maybe we could make it a real button instead of a link-button, because I find them confusing… I was happy when "Move to Trash" recently became a button 😄

[afercia]

Ah yes ideally buttons should look like buttons 🙂this is a long standing issue also in core where there's some uncertainty about what a UI control is: link? button? will it work with spacebar? We'll see.

Worth reminding visibility and publish are also available in the publish panel, same issue there:

[folletto]

Visibility: Public (<button>Change <span class="screen-reader">visibility</span></button>)

Just to make sure it's not missed: the mockup above also specifies semantic markup that uses the for label to associate the label on the right to the button itself, which is used by assistive tools to mark the button properly — i.e. it's used as speech which differentiates the two buttons even if they have the same label.

[davewhitley]

Here is a proposal for a possible compromise or alternative solution. A couple of concerns I attempted to address:

• The click target is much too small, and requires high dexterity to click the small link (applies to both Classic and Gutenberg editors).
• The font size is small and hard to read.
• As mentioned several times above, the linked text does not describe the action.

Some notes on the design:

• The icons used are just examples, we can switch them out for different icons.
• The whole row is clickable, providing a large click area.
• Similar to how the X icon means "close" and the cog icon means "settings", the pencil icon is widely understood to mean "edit".

I admit that I'm not well-verse in the intricacies of speech recognition software, so any guidance on that would be appreciated.

If this is a viable solution, I'd like your feedback on it!

Update: I removed the left decorative icons because they were unnecessary.

[anevins12]

The whole row is clickable, providing a large click area.

I think that would be unpredictable to people using speech assistive technologies. What do they say in order to edit the publish date, do they say "Publish date", or "Publish date october 9, 2018 7:27", or do they say "Publish date edit". I recommend keeping labelling for the interaction succinct and predictable.

[tofumatt]

We can use aria-label and keep the clickable area large; the increased click area improves accessibility for mouse users, especially those for whom small, precise click targets are an issue.

I love @drw158's design here. For screen readers I'd imagine we'd want to use an aria-label that read something like "Publish Date (click to edit)" or something like that? Could we use aria-describedBy for the date itself? 🤷‍♂️

[sinabahram]

Please note that aria-label will affect the accessible name of the component in question; therefor, it should be tested that speech recognition software still triggers the given component based off of the visible lable.

also, I suggest not using modalities in labels, but definitely not click at any rate, since the very audience the label is targeted for can’t use said input modality for the most part 😊

there used to be an issue whereby aria-label, but not aria-describedby, would make it into the Braille Display representation of a component, so you may wish to chain together an aria-label and aria-labelledby so as to affect the accessible name but not the accessible description of the component for purposes of Braille users.

Hope that helps.

[afercia]

Thanks @sinabahram. I'd add that UI controls that use only icons like the proposed "edit" buttons above don't really help. As mentioned in the previous comments and in various other issues in this project, controls that use only icons should be avoided at all costs. (speech input users, low vision, cognitive impairments, etc.)

[alexislloyd]

I think @afercia's original point here is a good one:

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.

I think @drw158's design does a very good job of addressing this, and also creates a larger, more usable click area in the process. This, in addition to @tofumatt's point about using aria labels for clear non-visual controls, seems to be a good solution.

As a secondary note, in re:

controls that use only icons should be avoided at all costs.

My understanding from accessibility guidelines is that the requirement for non-text content is to make sure there are text alternatives — alt text, aria labels, tooltips, etc. While visible text labels on controls are desirable in some cases, if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

[joyously]

if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

I can understand this sentiment, but I think it does not take into account the cognitive overload for those of us that can't decipher icons. We either can't see them well, or have no idea what they mean. I read English, not hieroglyphics.

[alexislloyd]

I can understand this sentiment, but I think it does not take into account the cognitive overload for those of us that can't decipher icons. We either can't see them well, or have no idea what they mean. I read English, not hieroglyphics.

I think this is where tooltips and alt text come into play, to provide additional context if an icon isn't apparent. This is where it's a balancing act of finding a balance of usability for everyone, understanding that increasing accessibility for one user may decrease accessibility for another. This isn't to discount any one experience, just to acknowledge that there's no perfect answer.

[afercia]

My understanding from accessibility guidelines is that the requirement for non-text content is to make sure there are text alternatives — alt text, aria labels, tooltips, etc. While visible text labels on controls are desirable in some cases, if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

@alexislloyd thanks for your feedback. Totally agree it's a balancing act. However, I don't think a _short_ visible text like "Edit visibility" adds more cognitive load than what an icon does. I'd say icons are way more problematic.

From an _usability_ perspective, I could cite a well known study about Icons Usability from the Nielsen Norman Group, and there's plenty of research about the cognitive load added by icons, cultural differences, lack of universal meaning, cognitive impairments, etc.

More generally, I'd like to invite everyone to consider that "icon-only" UI controls are part of what I'd call an "appification" design trend which, in my opinion, doesn't really fit with the true nature of the Web. Mobile apps live in a controlled environment where even the hardware is known. Pattern and paradigms used on mobile apps aren't necessarily good for web applications.

Instead, the Web is designed in an "agnostic" way, is designed to work for everyone whatever their hardware, software, language, location, or ability. In this sense, icon-only controls are an anti-pattern.
Of course, for what is worth, this is just my personal opinion.

I can understand the "clutter" argumentation but I'd easily argue that an user interface should be designed around its content, not the other way around. If there's not enough space, then I wonder why this part of the UI has been designed this way in the first place.

Re: text alternatives. Correct, but when it comes to UI controls things are a bit different. The _name_ of an UI control needs to be _perceived_ by all users. As accessibility team we've asked to have _at least_ tooltips to expose the controls name. However, that's a trade-off. Not all users are able to use a mouse to hover a control and reveal its tooltip or use a keyboard for the same purpose.

Consider speech input users: they need to _see_ a control name to be able to voice a command. They can work around this issue but that requires tabbing multiple (sometimes dozens) of times to get to a control to make its tooltip appear. I'd like to invite @ewaccess to explain better what are the needs of speech input users and why _visible control names_ are always preferable. Eric when you have a chance, that would be greatly appreciated thanks 🙂

Worth noting the accessibility team published a few user testing sessions. In one of them (shared in a make blog post and also with the Gutenberg team on Slack) @ewaccess was so kind to run a 1 hour testing session on Gutenberg. See https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/ I'd recommend everyone to watch that video to get an idea what a person has to do when UI controls don't expose their name visually. The session is from March 2018, many things in Gutenberg have changed, but the icons issue is still there.

I'd also invite to take into consideration a recent user testing session that was shared on Slack in the #design channel. One of the tasks asked to change the image in an Image block. Users took from about 1 minute and a half to 4 minutes (4 minutes!) to understand what they had to do. Most of them _totally ignored the "pencil" icon_. And they were users with no specific accessibility needs. Admittedly, a block toolbar has many icons and I guess that contributed to the confusion.

Comparing the Classic Editor with the proposed design: these controls in the Classic Editor are far from perfect but at least there's some visible text. In the proposed design, the controls are just icons:

In the proposed design I really appreciate the setting _state_ is separated from the setting _name_ but I'm wondering why to use icons in the first place when there's no actual need for them? I'm not a designer so what you see in the screenshot below is something I've just edited in my browser and can certainly be refined 🙂

Why can't we add the word "Edit" so that the controls names match the controls actions? Added bonus: this way, the clickable area would be larger.

Note: ideally, in the rendered markup, the actual values (e.g. "Public" and the date) should not be within the button element.

[ewaccess]

Consider speech input users: they need to _see_ a control name to be able to voice a command. They can work around this issue but that requires tabbing multiple (sometimes dozens) of times to get to a control to make its tooltip appear. I'd like to invite @ewaccess to explain better what are the needs of speech input users and why _visible control names_ are always preferable. Eric when you have a chance, that would be greatly appreciated thanks 🙂

Thanks @afercia!

Speech recognition users "say what we see." The only viable options for desktop speech recognition are Dragon NaturallySpeaking and Windows Speech Recognition (WSR). Both of these work by having the user say the word "click" followed by "[name of the thing they want to interact with."

Consider the microphone icon in the search box on Google.com. What do I say to activate it? "Click microphone?" It turns out that the label for this control is "Search by voice," so that's what I would say. I learned that by reading the tooltip on mouseover, but many speech recognition users cannot use pointing devices at all.

Consider the icons on the Github editor. Some are easy. "Click bold" and "Click italic" are rather obvious. But the "aA" icon? Without mousing over and finding that tooltip, I would have no idea that I need to speak "click Heading" to activate it. Personally, nothing about that icon conveys "heading" to me. The icon is doubly confusing because Microsoft Word uses a very similar icon on the Office Ribbon to mean "Change Case.' That would've been my first guess at what that control did.

By using icons instead of text labels, users need to:

1. Discover the label
2. Remember what they've discovered and apply it to a particular context
3. Discover if what they can say say actually works. For instance, Dragon users can interact with controls labeled using aria-label, but not aria-labelledby. That's a quirk in the user agent that developers needn't really be concerned about, but at least by using text labels you've left the user with one variable to contend with instead of three.
-

[joyously]

What if there were some setting that switched the interface from text to icons? Then people could figure everything out, and use the icons if they prefer.

[alexislloyd]

So, a couple of points:

• First, when discussing the icon, we need to be mindful of all of the substantial context around it that clearly indicates what affordance is available. This is present in a settings panel, adjacent to a setting name. It is a fundamental understanding of software that you can click on settings to edit them. The icon is helpful as an additional signal that this setting is clickable, but I think the extensive contextual information is more than sufficient to clearly communicate to anyone who is sighted. As already discussed, for those with visual disabilities, there is explicit supporting information to replace that visual context.

• Second, as we make decisions like this, it's useful to not just think about a one-off solution, but a solution that can be extensible and form the basis of a repeatable pattern for similar interactions. The more we can create that consistency, the more usable the overall product will be, as users won't have to relearn new patterns for every task.

So with that in mind, here is a rundown of several solutions that could be considered and how they stack up in terms of both clarity and extensibility. I laid this out in an image, but am also providing a text version below for anyone who can't see the image.

Option 1

Image description:
Each setting heading is the title of the setting (Visibility, Publish date), and the line below is the current status of the setting in smaller text. There is an edit icon to the right.

Clarity and hierarchy:
Easy to scan, hierarchy is clearly delineated
Each visual area represents a different aspect of the information:

• Header text on the left describes the setting
• Smaller text beneath shows the setting state
• Icon on right indicates the setting control mechanism.

Pattern extensibility:
Highly extensible pattern. We could easily have a document or block sidebar with many fields like this, as the pattern of setting description, setting state, and setting control is not one likely to break (and setting state could be removed in cases where not needed).

Option 2

Image description:
The setting headers read "edit visibility" or "edit publish date". The line below is the current state in smaller text. The right side has an edit icon.

Clarity and hierarchy:
Hierarchy is confusing, difficult to scan
The header text on the left is redundant with the icon on the right but is presented as a header for the current state below, even though it doesn’t describe that state.

Pattern extensibility:
Not very extensible. “Edit” may not work semantically with all setting names, this field could become very long in translation to non-English languages.

Option 3

Image description:
Each setting header text is the current status of that setting. The line below reads "edit visibility" or "edit publish date" in smaller text. The right side has an edit icon.

Clarity and hierarchy:
Hierarchy is slightly better but still has the issue of the control text and the control icon being in different visual spaces / not clearly connected.

Pattern extensibility:
Not very extensible in that the pattern relies on the setting having a current state to serve as the header, which it may not (or that current state may not be something expressed in words, like a color or an image).

Option 4

Image description:
Individual settings are represented by select / dropdown menus with a header (Status or Visibility) and the current status.

Clarity and hierarchy:
Hierarchy is clearly defined, relatively easy to scan, though the addition of the outline around the select control adds clutter that reduces scannability.

Pattern extensibility:
Somewhat extensible , but may run into problems if the current state is something visual (an image, color, etc.)

Option 5

Image description:
Individual settings don't have headers, and are represented by select/dropdown menus that display the current status of the setting.

Clarity and hierarchy:
Easy to scan but provides less detailed contextual information about what each field is showing.

Pattern extensibility:
Not very extensible in that the pattern relies on the setting having a current state to serve as the header, which it may not (or that current state may not be something expressed in words, like a color or an image).

In short, we're trying to collectively solve the initial issue that was raised here, and to do so in a way that not only solves it in this instance but provides a consistent pattern to follow. Consistency is something that needs to be improved in Gutenberg and is a huge consideration for accessibility and usability across the board, which is why I'm focused on coming up with a solution that isn't just a one-off for this instance but can be applied consistently in instances like this as well. I think option 1 addresses the initial issue and increases accessibility and usability with a larger font, larger click area, clearer information layout, and the intent to have all of that supported by the appropriate alt and aria labels for screen reader / voice concerns. I propose that option 1 represents the best balance of usability, accessibility, clarity, and extensibility and is the best choice to move forward with.

[afercia]

@alexislloyd thanks for your feedback and for the effort. I personally kindly disagree, but I'll wait to discuss this issue with the accessibility team and come to a reply as a team.

I appreciate all the considerations about hierarchy and consistency. I'm a fan of consistency and typography so I look forward to seeing more and more of them in WordPress.

That said, I see what prevails is a _visual_ approach. If we want to succeed in making this project deliver the best balance between accessibility and visuals, we need to learn together to _not think visually_ as a first step. Semantics and meaningful information come first. Seems to me there's not enough consideration for what an UI control should communicate to all users and to software used by users.

For example, Option 1 wouldn't solve the issue for speech input users.

Option 2: the icon is redundant and should be removed. I don't see any reason for an icon when the button text already communicates the available action, e.g.: "Edit visibility". From an accessibility perspective, I think this would be the best option.

Option 3, 4, and 5 are interesting explorations but I think we agree they're less than ideal 🙂

[joedolson]

Is there any crucial need to remove the icon? I'm not sure I can see the accessibility need for removing that icon, as long as it's only supplemental and doesn't carry additional text that would influence the accessible name of the control. For cognitive impairments or people less comfortable with the language, supplemental icons can help identify the purpose of a control more quickly.

[afercia]

@joedolson in the proposed design, text is only text. The actionable control _is_ the icon.

[joedolson]

Ah, well yeah - that's a problem. The text should be the control.

[sinabahram]

+1: I agree. The text should be the control.

[youknowriad]

From what I understood from the design, the actionable control is not the icon only, it's everything. I think this needs implementing to see if it can be made accessible or not, we can't judge by just looking at mockups.

[afercia]

From what I understood from the design, the actionable control is not the icon only, it's everything

Then this should be clarified. If the actionable control is a <button> with a text that clearly communicates the available action, e.g.:

• edit visibility
• edit publish date
  and the icon is purely decorative, then I guess there are no accessibility concerns.
  The text representing the state must _not_ be included within the button tough. It should be referenced by an aria-describedby attribute. We'd need to explore some CSS technique to keep it outside of the button, while keeping the whole box as the clickable area.

[anevins12]

You can also use JS to apply the behaviour of the button to the parent element, while still retaining the focus order of the button. So that you can tab to the button and interact with it normally, but as mouse r touch users you can click on the whole area

[joyously]

I was a little confused just looking at the mockups, when there is an icon and text. It's as if there are too many choices (clutter), but I didn't know if I should click the icon or the text that looks like a link. Is accessibility only about impairments? Or am I impaired, since I find it difficult to navigate with all the unknown icons in the way?

[tofumatt]

Because this is still somewhat in discussion, but also because it needs implementation and is a big (UI) change, I'm moving this out of the 5.0 release milestone. I've moved it to follow-up for now.

[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.