Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block inspector: tabs slot fill should appear below post/block buttons in DOM #47623

Open
alexstine opened this issue Jan 31, 2023 · 4 comments
Assignees
Labels
[Feature] Inspector Controls The interface showing block settings and the controls available for each block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended

Comments

@alexstine
Copy link
Contributor

Description

In the block inspector, while the block tab is selected, the sub tabs slot fill can contain content above the slot fill which may make the tabs less discoverable to screen reader users. The sub tabs should appear below the post/block tabs and directly above the close button. This slot fill probably should not be a slot fill at all, it should be dedicated to tab navigation without the ability for developers to add other content that could distract from the sub tab navigation experience.

Step-by-step reproduction instructions

  1. Open a post.
  2. Insert some blocks, ensure one of them is a group block.
  3. Select the group block.
  4. Tab into the block inspector.
  5. Notice how you tab across Post, Block, and then Close.
  6. At this point, it is reasonable for a user to not expect tabs because the other buttons (fake tabs) are located above the close button.
  7. Press key tab again and you will land in a grouping of options called: Transform to variation.
  8. After this group is the sub tabs.

Screenshots, screen recording, code snippet

No response

Environment info

Gutenberg: trunk
OS: Windows 10 Professional
Firefox: latest
WordPress: 6.2-alpha-54678

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

@alexstine alexstine added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Feature] Inspector Controls The interface showing block settings and the controls available for each block [a11y] Keyboard & Focus labels Jan 31, 2023
@aaronrobertshaw
Copy link
Contributor

Thanks for submitting this issue @alexstine 👍

the sub tabs slot fill can contain content above the slot fill which may make the tabs less discoverable to screen reader users

Is the content you mention here the block info card and block variations as indicated in the reproduction instructions?

This slot fill probably should not be a slot fill at all, it should be dedicated to tab navigation without the ability for developers to add other content that could distract from the sub tab navigation experience.

I'm not sure exactly which slot fill you are suggesting shouldn't be a slot fill. Could you please expand on this for me?

Also, while I'm seeking your wisdom, how do you see the proposed switch of the Post/Block (fake) tabs to a TabPanel component, impacting the sub-tab navigation experience being discussed here?

@alexstine
Copy link
Contributor Author

@aaronrobertshaw

Is the content you mention here the block info card and block variations as indicated in the reproduction instructions?

Yes, it is.

I'm not sure exactly which slot fill you are suggesting shouldn't be a slot fill. Could you please expand on this for me?

I am not sure if the slot fill is a slot fill at all, point was, it should not be. I am referring to the area where the sub tabs are injected in the inspector. I think a slot fill after the sub tabs is okay but not before. What we do not want is other developers to have somewhere to inject content that can badly impede inspector navigation.

The flow should be from the fake tabs, sub tabs, the close button, and then the rest of the content. Developers should not be able to add anything until after the close button.

This help? Thanks.

@aaronrobertshaw
Copy link
Contributor

Appreciate the clarifications @alexstine, thanks.

I am not sure if the slot fill is a slot fill at all, point was, it should not be.

The block's information and its transforms aren't a slot fill. Currently, these are rendered above the sub-tabs on the Block tab as you noted. In case it interests you, where this happens can be found in the block inspector here.

Given the BlockCard and BlockVariationTransforms components do not render children via slot fill, developers can't inject any further content above the sub-tabs. The BlockCard renders information derived from the block type definition, while the BlockVariationTransforms are retrieved from the block store.

I think a slot fill after the sub tabs is okay but not before.

If a block is to render tabs, all the slot fills for the InspectorControls will render within those tabs. If a block isn't to render tabs, all the slot fills will render directly into the content of the Block tab underneath the block info card and variations.

The flow should be from the fake tabs, sub tabs, the close button, and then the rest of the content.

This is the aspect of this issue that requires some action and a little time to figure out how to achieve it.

Developers should not be able to add anything until after the close button.

It's my understanding that at the moment, they can't as all the slot fills for the InspectorControls are rendered within the sub-tab panels.

@alexstine
Copy link
Contributor Author

@aaronrobertshaw This all makes sense then. Now the hard part, figuring out how to re-order the DOM without making a design mess. I will let you decide how this moves forward as this is not an issue I can work on due to the visual complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Inspector Controls The interface showing block settings and the controls available for each block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants