-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Template Part Block: Use buttons for area selection #30005
Template Part Block: Use buttons for area selection #30005
Conversation
Thank you!
Yes! Now updated. I'm a little unsure about the screen reader accessibility of using tooltips to describe the template part areas. I modified the Tooltip component to be able to receive an id and be the target of aria-describedby (declared on the buttons)--this seems to help when testing with VoiceOver, but I'd want a more experienced opinion before merging this. |
position, | ||
text, | ||
shortcut, | ||
...popoverProps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm 🤔 This seems to be a rather big modification. I wonder if we should use an explicit popoverProps
property instead of ...
rest. We need to update the README too.
As a last thought, maybe we should move this to a separate PR?
It's working as expected. My only concern is the modification of the Screen.Recording.2021-03-22.at.9.58.18.mov |
+1 to moving the a11y discussion to a separate issue since it will effectively relate to all tooltip usage across the app. |
@creativecoder Could you break this into multiple PRs? We should remove the tooltip changes from this PR and create a separate PR for just the tooltip. Then we can create a follow-up PR to add the accessibility parts once we have the tooltip PR merged. You can use the tooltip PR as a base for the follow-up PR so we can show a use-case as well in the tooltip PR. So basically we will have 3 PRs in the end:
|
Yes! Will work on that soon. I'd like to leave the className passthrough (Tooltip prop that's passed to the Popover component) so we can control the tooltip width. That seems less invasive, and therefore okay? I'll be sure to update the component readme, accordingly. |
I would be still concerned about the PR's responsibility. In my opinion, it's better to avoid making core changes in a mostly Site Editor related PR. Smaller PRs and single responsibility PRs are easier to revert and discuss. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor thoughts, its lookin pretty good so far. 😁
value={ area } | ||
onChange={ setArea } | ||
/> | ||
<BaseControl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if RadioGroup
/Radio
components would be able to fit well and be adaptable for this case? It seems pretty similar visually and behaviorally to what we are going for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for RadioGroup and Radio components. They seem to fit this particular situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the idea, I will take a look.
description: __( | ||
'The Header template defines a page area that typically contains a title, logo, and main navigation.' | ||
), | ||
icon: header, | ||
label: __( 'Header' ), | ||
value: 'header', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not something that needs changed in this PR, but we should centralize these descriptions/definitions so we don't need to re-define them in a handful of places. I'm trying that as part of #30395, so a follow up once these both land would be to update this to get that data from the core editor store.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the design. If the width has to be fixed in a follow-up PR, so be it :D
👋 Would love to see this merged 😄 Could you rebase it? Happy to approve once tests are passing and rebased. We can create a follow-up PR for the a11y comment. |
Closing in favor of #45764, which uses the newer ToggleGroupControl component. |
Description
Resolves #29295
How has this been tested?
Screenshots
Template Part Block > Advanced settings in sidebar
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: