WordPress
Find alternative solutions for surfacing the HTML markup control in the Separator block
In https://github.com/WordPress/gutenberg/pull/70185 the HTML Select control of the Separator block was moved from the advanced inspector (where it lives for every single other block that has this control) so the top level inspector area.
This change was done to improve the accessibility of the separator block because in most instances the separator should not be a literal hr element but rather a span/div without semantic meaning...
I can totally understand the need to surface the control more in the UI.
What I am concerned about, is that the way this was done caused a large regression in the usability for all the other controls of the block.
All the design tools of the separator block were accessible without needing to click on anything in the sidebar. Now with this change the sidebar is split into the settings and the design tabs which means all the controls that were previously directly accessible without needing to click anywhere are now hidden behind a tab. And instead we just have a whole bunch of whitespace in the sidebar creating a really subpar experience.
CC: @amberhinds @t-hamano
I can understand both opinions, but I tend to agree with Fabian.
I think that users who don't know what HTML is might be confused when they see this UI.
One idea might be to add a "decorator" variation to the separator block that is rendered as a div element to clearly separate the roles, but this might be redundant.
I am going to give feedback on what has been proposed and try and then look to see what we can do going forward.
First: https://github.com/WordPress/gutenberg/pull/70185 was done without design feedback which I strongly advise we don't do going forward. It is important to have consistency of controls. I appreciate the understanding here of the type though, but we now have a confusion.
As @fabiankaegy says:
What I am concerned about, is that the way this was done caused a large regression in the usability for all the other controls of the block.
I also think this is what we now have. We have consistenly told people where to look for something and now moved that.
@t-hamano whilst I understand what you are suggesting:
One idea might be to add a "decorator" variation to the separator block that is rendered as a div element to clearly separate the roles, but this might be redundant.
To me, this complicates if further.
I wonder if a calmer approach is to consider what the original issue is and whether we can collectively come up with a solution rather than isolating design and accessibility as seems to have happened in the past issue without getting design system/usability feedback also.
I want to therefore take some time to consider the feedback of @amberhinds and look at what options we have:
Decorative elements should not be read out by screen readers as it add excessive noise to the page and can be confusing. Most uses of separator blocks that I have seen on WordPress websites are decorative and not meaningful. Some websites use it excessively, causing pages to be almost unintelligible.
There should be a way for users to indicate that the separator is decorative or meaningful in the block settings. If the block is marked as decorative, aria-hidden="true" should be applied to the block or the separator should be built with a
with border-bottom instead of an
.So can't we have an indication on the block over just taking out the entire block? It seems simpler than adding a variation also and moving things.
Now reading a bit more the suggestion is:
Possibly, the default on the separator should be set to decorative and hidden, as nearly all uses of it (in my experience) are decorative. So they would always have aria-hidden="true" unless the user toggled a setting to "Announce separator to screen readers."
I would argue the reverse might need to be the case or we do the following:
- Show the option checked.
- Still have settings there but grey them out.
What we need to do is avoid moving settings or disrupting patterns. This also stops moving things. What I don't want to do is go against the amazing accessibility advice, but I also want to make sure we get consistent design here.
So the challenge I would suggest is:
- How do we not move the settings and still keep the advice of accessibility?
@troychaplin I would be curious how you would create a PR based on this design feedback which ideally we should have had during the process for consistancy also.
In giving this I want to not be the only person to block design feedback, we can use the labels to ensure others can jump in. We have 'needs design feedback' and 'needs design' as labels which can ensure people can get support just like acccessibility. Apologies if these were added at any point and missed but I didn't see they were.
Thanks @karmatosed ❤️
From my perspective here we should seriously consider if we shouldn't revert https://github.com/WordPress/gutenberg/pull/70185 for the time being because I think it creates more a11y issues than it solves.
For users using assistive technology 10+ features that were previously accessible directly are now hidden behind a tabbed interface. So by moving one singular (yes important) control out of the accordion for advanced settings we have made 10+ settings much harder to get to. And these controls aren't much less important. Making sure the color of the separator has enough contrast for example.
I want to find a solution that solves both problems ideally.
But in the mean time I think the change in https://github.com/WordPress/gutenberg/pull/70185 is a clear regression that should get reverted.
But in the mean time I think the change in https://github.com/WordPress/gutenberg/pull/70185 is a clear regression that should get reverted.
I agree with this suggestion. To be precise, #70185 makes two changes:
- Move the UI out of the Advanced panel.
- Adds help text about the selected element.
I think we can revert only the first one.
I'd like to move #70455 forward. If you have any additional feedback on this PR, I'd love to hear it.
With moving this back into the advanced settings, which I understand, can re-visit what the "default" is and whether the default can not be an <hr>?
@joedolson said that changing the default could be a problem, but I don't fully understand why. Could someone please explain that to me?
Hi @amberhinds 👋
Yeah I also really want us to find a solution that helps both problems at the same time. And I agree that it would probably be the nicest solution to have the new default be the span...
The problem that we run into with this is a very annoying one but one that I'm not sure I've seen a good solution for. If we changed the default for the block it would not just affect all newly inserted separator blocks that get inserted. Interestingly enough it also wouldn't just update all old instances of separator blocks. Instead it does something even more confusing. Because of the way that static blocks are built, the full markup of the block is saved to the post content. So if we changed the default today, it would affect all separator blocks going forward and all old separator when any content that contains them gets opened in the editor again and re-saved....
So it would also affect old content that was created before this change when the user changes anything in that content. And the user isn't notified about these updates.
It is technically possible (by adding a new block deprecation) to make this change. But it has these side effects on legacy content...
Technically speaking it would be possible to architect this in a way (by using a PHP render_callback) to update 100% of all separator blocks. So that every existing instance is affected.
But for both of the approaches I outlined I myself even have many historical examples where I used the separator block intentionally to get a <hr> element which would just get overwritten by this change here. This may be problematic from an a11y standpoint and also when themes (incorrectly so but nothing really we can do about it) applied styles to the <hr> tag rather than the wp-block-separator class...
All that said I am pretty stumped on what other solutions we have to make that update. If anyone has better / alternative ideas I'd love to hear them :)
It sounds like we need a system for alerting users in the UI when a block has been changed before a save action.
I appreciate this detailed explanation, it helped me understand the impact.
Technically, we should be able to decide whether to change the elements of existing Separator blocks by using the migrate property.
Do not change the elements of existing Separator blocks
The default element of newly inserted Separator blocks will change from hr element to div element.
My concerns:
- Users who use
hrelements "correctly" will be forced to go through the trouble of changing fromdivelement tohrelement every time. - Unless users are aware of this change to the default elements, they may end up with a mixture of existing
hrelements and newly inserteddivelements. - Styles will be broken in themes that apply styles to
hrelements.
Migrate Separator block elements where hr elements are used to div elements
When you edit post content and save the post, Separator blocks where hr elements are used will be converted to div elements.
My concerns:
- This will break the structure of content for users who use hr elements "correctly".
- Styles will be broken in themes that apply styles to
hrelements.
Either way, I personally don't recommend changing the default elements as it has significant backward compatibility implications.
At the root, we really need two different separator blocks. One that's structural, and one that's decorative. Both are legitimate uses, but the latter is probably more common, while the former is the actual default.
Maybe what we really need is some decorative variants of the Spacer block, which is already semantically neutral.
Maybe what we really need is some decorative variants of the Spacer block, which is already semantically neutral.
I can think of two approaches to this.
The first would be to add the "Decorator" block that can be inserted as a block variation. See https://github.com/WordPress/gutenberg/issues/70441#issuecomment-2976484927
Another approach is to make it easier to change elements by allowing variations to be transformed from the block sidebar.
Example:
https://github.com/user-attachments/assets/3072052e-e661-474f-89e4-38aec50d8bfa
The only issue I have with this is how do people know what a line with lines on the end versus a line without lines on the ends means? This does make the control more visible, but I wouldn't expect people to ever toggle it because the icons are ambiguous.
Is there an approved icon set? Maybe there are different icons? Or can it use words instead like the button block does?
Honestly, that's a global problem throughout the editor. The controls would need some kind of text indicator or tooltip to explain the difference.
But if this toggle is changing it between being purely decorative and being structural, I think that needs to be more clear. This is why I'm not convinced that calling it the "decorator" block makes sense - if it can either be decorative or structural, then calling it 'decorator' is semantically ambiguous.
I'm personally fine with Separator only being a structural block. In my opinion, if you're inserting a separator, then that is a structural choice. You're inserting separation, which should be both visible and structural. If you're inserting a spacer, then you're just inserting space, and that should not be structural. The problem we have right now is that there is no method to insert visible separation that is not also structural.
It seems like there are three choices:
- Allow the separator block to change elements.
- Allow the spacer block to serve decorative styles.
- Add a new block that can serve either purpose.
Adding a new block is probably the easiest path; it just needs a good name that conveys what it does accurately, and a clear option to switch between states.
@joedolson I pretty much agree with your assessment here. But in regards to your three choices:
- Allow the separator block to change elements.
We already have that today. The toggle is just located in the advanced settings tray and got moved to the main settings which caused several regressions making multiple other controls much harder to reach.
- Allow the spacer block to serve decorative styles.
This is up to each individual theme. The foundation for it exists today
- Add a new block that can serve either purpose.
I hear what you are saying but in my eyes that just adds to block inflation and causes even more confusion...
From my POV we should merge https://github.com/WordPress/gutenberg/pull/70455 for now and then we can continue to think though alternatives
The only issue I have with this is how do people know what a line with lines on the end versus a line without lines on the ends means?
This is just a PoC, we can create a proper icon if needed.
Or can it use words instead like the button block does?
Currently, the block transformation UI only supports one of the following UIs:
| Render transformations as icons | Render transformations as text |
|---|---|
From my POV we should merge https://github.com/WordPress/gutenberg/pull/70455 for now and then we can continue to think though alternatives
I agree with this. Just to be clear, please note that merging #70455 does not mean that there will be any regressions compared to WordPress 6.8.
| WordPress 6.8 | Gutenberg trunk | PR 70455 | |
|---|---|---|---|
| description | Placed in the Advanced panel | Placed in the Settings panel with a description | Placed in the Advanced panel with a description |
| screenshot |
Couldn't the current variant be renamed to Horizontal rule, and the new variation that uses a <div> can be the separator?
Decorator to me sounds like something that would allow much more decoration options than what is currently available.
Couldn't the current variant be renamed to Horizontal rule, and the new variation that uses a
<div>can be the separator?
If we are going for the approach of adding variation to the spacer blocks, I think this is a good idea too.
Let's move forward with #70455 for now. #70455 doesn't introduce any new accessibility issues compared to WP 6.8. Instead, it's a friendlier UI with added help text.
However, we'll keep this issue open until we find a more ideal approach.