Fix accessibility of the post summary controls

[afercia]

Description

Follow-up to #470
See #63308

All the controls (buttons and links) in the post summary panel are labeled in an unclear and misleading way as their labels uses the value or state of the control rather than communicating what the control does or is about.
This was originally discussed long time ago in #470. Since then there have been minor improvements but the underlying issue is still not fully solved.

Buttons should communicate what their action is about.
Links should communicate the link destination or purpose.
They are not places to communicate a value.

Screenshot of the current UI:

In the following screenshot I removed the CSS to better illustrate the buttons and their text labels:

All these buttons text is the currently selected value, which is less than ideal.

The only minor improvement since #470 is that some of these buttons have now an aria-label that gives more context by prepending the button action to the value. Still, less than ideal because the visible text mismatches the actual accessible name. The mismatch is a barrier for sighted screen reader users and speech recognition software users.

Examples of the aria-labels:

• Change post status: Published
• Change date: July 22, 2024 1:40 pm UTC+5:45
• Change link: my-post-title
• Change author: admin
• Template options (entirely mismatch the visible text)
• Change discussion options

Worth reminding the panel may render additional controls depending on the edited object e.g. Format, Parend, Order. It may also render values that arent interactive controls e.g. Sync status.

#63308 reports additioanl issues for these controls, for example:

• The Revisions link text is just a number with no other context.
• Some of these controls use tooltips to add more context but they do that in an inconsistent way.
• There's no semantic indication that some of these controls open the related popovers.

While the addition of the aria-labels improved a little these controls for blind screen reader users, the labeling is still lss than ideal.

Proposal

The visible text of the controls e.g. Status, Publish, Link, Author, etc. are just 'visual labels'. Plain text with no semantic association with the controls. I'd like to propose to make the visual labels the actual buttons to edit the settings and the displayed values just plain text. Quick screenshot to better illustrate:

• The visual change would be minimal.
• The controls visible text would clearly identify the controls action.
• Some special cases would need some adjustments e.g. the 'Template Options' to avoid the need tor a tooltip.
• Although not 100% ideal, I'd would even consider to not use any aria-label attribute to clarify the controls as they would be sufficiently understandable.

Optionally:

Consider to make the whole 'row' the actual clickable area. A larger target size always helps. The visibel text of the value could be made hidden from assistive technology and used for an aria-describedby attribute to communicate the current value in an accessible way. Quick example:

Pseudo markup:

<button aria-describedby="status-description" ... >
    Status
    <span aria-hidden="true">Draft</span>
</button>
<div id="status-description" hidden>Current status: Draft</div>

Cc @joedolson @WordPress/gutenberg-design

Step-by-step reproduction instructions

• Edit a post
• Observe the Post summary panel in the Inspector
• Inspect the source of the buttons and observe their text doesn't communicate the button action.
• Observe the buttons aria-label mismatches the visible text.

E.g.:

<button type="button" aria-label="Change date: July 22, 2024 1:40&nbsp;pm UTC+5:45">
    July 22, 2024 1:40 pm UTC+5:45
</button>

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[hanneslsm]

I'd like to propose to make the visual labels the actual buttons to edit the settings and the displayed values just plain text. Quick screenshot to better illustrate:

From UX perspective I'm not a big fan of this.
Sighted users are used to click on the value they want to change, therefore it should be blue and indicating that it's clickable. Dropdowns or other elements use this UX pattern.

Consider to make the whole 'row' the actual clickable area.

That'd be fine, if we keep the description / label blue.

[hanneslsm]

Plain text with no semantic association with the controls. I'd like to propose to make the visual labels the actual buttons to edit the settings and the displayed values just plain text.

The only way I could imagine this could work is by changing visually the values to make it clear "it's data". I'm not a fan of this either though.
Quick draft:

[afercia]

Thanks for your feedback.

Sighted users are used to click on the value they want to change

Any data, user testing or any other reference to support this statement?

I'd like to remind once again, as discussed since #470 more than seven years ago, that this isn't just about visuals. It's about semantics, accessibility, and how to properly label buttons.

Using this kind of text for a button:

or this:

or this:

is, honestly, very arguable.

Dropdowns or other elements use this UX pattern.

That's right and it's because a <select> element is designed to show the selected value. It's an entirely different control compared to a button. That's also why <select> elements need a visible label to communicate what they are about, because the selected value may not communicate it appropriately.

[richtabor]

Sighted users are used to click on the value they want to change
Any data, user testing or any other reference to support this statement?

Selecting "Link" to change the URL is objectively less clear than selecting the value you want to change. Like @hanneslsm mentioned, akin to dropdowns, but also the same UX for rows/tables of information. You don't click on labels to change a value—you interact with the field, the value.

I too disagree with making the labels the buttons.

I'd like to remind once again, as discussed since #470 more than seven years ago, that this isn't just about visuals. It's about semantics, accessibility, and how to properly label buttons.

I appreciate the reminder regarding the significance of semantics and accessibility. However, it’s important to recognize that visuals play a crucial role in user experience. Visual design directly impacts usability, cognitive load, and overall user satisfaction. Omitting visual design is detrimental to the project; let’s aim for balance.

[jameskoster]

Making the entire row interactive is an interesting idea. Would it improve a11y if we did that, but didn't change the appearance?

[joedolson]

It seems like the only argument here is against switching the colors so that the label is blue and the value is non-interactive text; the more important change is making the entire region clickable, so that the label is part of the button, and it doesn't seem to me like anybody has a problem with that change.

From my perspective, if the entire thing is clickable, I don't really care which part of it is blue, as long as a portion of the text contains a visual affordance that this is interactive. Users are already accustomed to the fact that you can click on a label element and it sets focus to the associated interactive element; so if the label is now clickable, that's great - it's an expected interaction.

So, in response to @jameskoster - Yes, it would absolutely improve accessibility if we combine both texts into the button without changing their appearance. The important change is that the purpose of the control would now be included in the text without requiring a mismatch between an aria-label and the visible text. While the text of the button would still change, it would only be part of the control's name, not the entire name - and the constant part would be the first part of the text, which is good for accessibility.

As far as I'm concerned, making this change with no visible alteration would be a significant accessibility improvement.

I'll also second the removal of aria-label attributes in this panel; it's always preferable to have the visible text be the label for a control, rather than depending on an alternate string.

[afercia]

Selecting "Link" to change the URL is objectively less clear than selecting the value you want to change

The problem I have with this kind of statements is that they're not supported by any data, research, specification, etc. Stating that something is 'objectively less clear' without providing arguments to backup that statament doesn't help in any way collaboration in this project. It doesn't help to improve the user experience too.

However, it’s important to recognize that visuals play a crucial role in user experience.

I totally agree. And, honestly, I would say the overall visual experience in the editor isn't great.

Visual design directly impacts usability, cognitive load, and overall user satisfaction. Omitting visual design is detrimental to the project; let’s aim for balance.

To me there's no such a thing like 'visual design' that is separated by semantics, accessible design, universal design or whatever we want to call them. There is 'web design', which is a discipline that includes many aspects and none of them is separated from the other ones. WordPress aims to be as accessible as possible. As such, designers must work in the constraints of accessibiity requirements, which is not different from other constraints they are already working with. It's a requirement of the project, not something to be continuously dismissed, deprioritized, or moved to the level of 'remediation', when it's already too late.

You don't click on labels to change a value—you interact with the field, the value.

Input fields and buttons are pretty different. These arebuttons, so the example above is out of context.

[jameskoster]

I reckon we should try making the entire row a button, potentially as a part of the Data Forms work.

[afercia]

You don't click on labels to change a value—you interact with the field, the value.

Input fields and buttons are pretty different. These arebuttons, so the example above is out of context.

I do realize my previous statement above needs to be expanded a bit. It's basically the same old issue from #470

Input fields

Sure, to change a value within an input field, we do click the value. The input field could be empty though, so there's nov value to 'click'. Also, clicking a proprly associated label moves focus to teh input thus achieving the same effect of clicking the value. But yes, visually we click the value.

Native input fields are simple, intuitive to use: Click the spot where the value is supposed to be set and edit it.

However, the controls in the summary panel are not input fields.

They are buttons that open the UI to edit the values.

Buttons

Native button elements are meant to submit a form or perform an action. We don't put a value or state inside the button. Instead, we do label the button to communicate what the button action is. Consider this example:

Would you ever put the Permalink value inside the button? That would be a very arguable usage of a button. Actually, that's what the summary panel does and that pattern is in place since seven years. The only proper usage for buttons is to label them to communicate the associated action. In the example above that is 'Edit'.

What to do in the Sumary panel

Ideally, I'd love to see the buttons have a meaningful label to communicate the associated action. E.g.:

• Edit Status
• Edit Publish date
• Edit Link
• etc.

As a compromise, I'd like to see the buttons be labeled at least with the 'what' as in: instead of explicitly communicate the action 'Edit', using the name of the setting would be an improvement. For no reason these buttons should be labeled with the setting value. This way, the button labels would at least clearly communicate waht they are about. E.g.:

• Status
• Publish date
• Link
• etc.

Visually, the button could be the entire row. I'm confident that we can hide from assistive technology the visible value and communicate it via the accessible description (aria-describedby).