Sidebar: Add list view tab for Navigation block et al. #45483
Conversation
aaronrobertshaw
added
[Type] Enhancement
aaronrobertshaw
requested review from
ellatrix and
tellthemachines
as code owners
|
|
| ? __( 'This block has no list options.' ) | ||
| : __( 'The selected blocks have no list options.' ) } |
There was a problem hiding this comment.
I'm not real clear on which blocks will be rendering what controls to this tab so the wording here is pretty poor. Any suggestions?
|
Size Change: +200 B (0%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
aaronrobertshaw
force-pushed
the
try/appearance-settings-tabs-in-sidebar
branch
from
568e3c3 to
60863b2
Compare
aaronrobertshaw
requested review from
spacedmonkey and
ajitbohra
as code owners
|
@aaronrobertshaw If this is meant to be block specific, why can we just not add a button in the block formatting toolbar or even inside the block placeholder as the image block handles this? I am just not understanding how to communicate to screen reader users that some blocks you edit in the block content and some blocks you edit from the sidebar. I cannot over stress how important consistency is. It is not A11Y compliant to have different patterns for different blocks. I am honestly kind of shocked this hasn't received more visual feedback as well considering it would be a confusing experience for everyone to have different blocks working differently. My point. The community needs to come together and figure out what the sidebar is going to be used for and then leave it well alone. Thanks. |
aaronrobertshaw
force-pushed
the
try/appearance-settings-tabs-in-sidebar
branch
from
60863b2 to
8530a42
Compare
aaronrobertshaw
force-pushed
the
add/list-view-tab-to-sidebar
branch
from
557b335 to
4bda26d
Compare
|
Hi @alexstine Thanks for your reply. I have some follow up questions:
|
|
@scruffian Sure, happy to go a little further. I know comments are not always as descriptive as necessary.
The other thing to think about is communicating things to users. Gutenberg is already very verbose. This means that users are required to listen to instructions everywhere to understand how the editor works. I am in favor of this only if it is necessary and I think introducing these changes for the sidebar will require us to communicate more info for users who can't see and it is already information overload. Imagine as a sighted user if you had to read tool tips all over the editor because the icons for the action you were trying to perform just did not make sense. The whole editor is still very much like this for screen reader users. Some parts are slowly getting better but other parts still suffer from enormous amounts of verbosity. Some of it is unavoidable such as communicating special shortcut key functionality or communicating the positioning of a block. All this information is stuff that the sighted take for granted because it is right there visually. All this stuff has to be consumed in different mediums for the non-sighted. Thanks. |
|
@alexstine, thanks for taking the time to reply. I really appreciate the detail in your response. I agree that ideally the mechanism for editing block content should be the same for every block. In the case of the navigation block, the nature of the visual display of the block makes it very different to select and manipulate the items using a mouse. When navigation menus contain submenus, these items are visually hidden which makes it harder to edit for users who are relying on the visual display and a mouse. The idea behind adding the list view to the sidebar is to display all the items, even those that are visually hidden (like submenus), so that visual editing is easier. From what I understand (and please correct me if I am wrong) it seems like you're saying adding additional controls to edit the block content in the sidebar doesn't add value for those using screen readers. This makes sense to me - if you're using a screen reader then visually hidden items will still be accessible, so the same concerns don't apply. What do you think of the idea of hiding the sidebar controls for screen readers? Since they already have a way to edit the content that works, maybe it's not necessary to give them another? I expect this is a bad idea, in which case I am very interested to understand more. Thanks for taking the time to reply, your help in this area is extremely useful to us. |
|
@scruffian It will not be possible to hide this content to screen readers without making it inaccessible to the keyboard at the same time. You need 2 things to hide major sections like this.
You cannot get by with one or the other because the first hides to screen readers but the second removes from the tabbable elements. If you only applied 1, screen readers would not understand why they keep hitting empty/hidden tab stops in the sidebar. If you applied both, sighted keyboard users would not be able to use it. Is the problem that the block itself is too small of a canvas area? Ever thought about adding an expand content button or edit block in new window type functionality? That way if a user is working with a really complex block, they could click a button and have the content render in a dialog or something removing all the other distractions. Thoughts? I actually attempted something like this in a PR long ago but just could not work out the logic for how the sidebar would fit in to the flow of editing. Being totally honest, the sidebar for blocks seems kind of wrong to start but I'll leave that up for another discussion later down the road. I doubt anyone will be jumping to get rid of it. Thanks. |
|
Great discussion @alexstine and @scruffian; I appreciate you both helping refine our approach here. 👍 I had a chat with @priethor today, where I proposed exploring another potential option that I'd like to get your thoughts on. It might not be perfect either, although I'm hoping we can get closer to a compromise that would allow this experiment to move forward. This new approach would include the following:
Some immediate downsides I can see with this approach are:
I'm sure there'll be others as well. Some upsides might be:
I'd welcome any better solutions, or ideas on how we could address the downsides above. |
Yeah, I can see this being a big problem for sighted keyboard users. How do we hide something visually and keep it accessible with the keyboard for non-screen reader users? I just do not think I will ever be sold on using the sidebar for this. Too much moving around and editing in different places. @joedolson Can you add some feedback on this? Maybe there is something I am overlooking? |
Why would this be an upside? The list view in the inspector is only relevant for blocks that manage their children, which is a small subset of blocks and optional for certain patterns. This notion has already been introduced for Also this affordance should not take away from being able to interact in the canvas. And a direct toolbar link to open this view should also not be discarded — it's what the "list view" in the navigation block toolbar should likely do, given before it opened a modal, now it opens a panel in the inspector. |
My understanding of the a11y concerns raised to date was that consistency trumped most things when it came to compromises. I thought then that keeping the tabs consistent in the DOM for screen readers was desirable. I've gone around in circles on this too many times and disregarded the impact visually hiding tabs would have on sighted keyboard users.
This aligns with my original intent for this PR, although I have been attempting to find a compromise that would also address the a11y issues raised. As this is behind a feature flag and is consistent with the existing
@alexstine, it appears we are back to square one here. There are a lot of benefits to being able to have this tab for the small subset of blocks that need it. I know, and appreciate, this isn't something you agree with, but I'd like to thank you for your continued input here 🙇 |
|
Consistency can be good or bad, depending on what is being made consistent. For example, it wouldn't make sense to show the Cover block focus point tool on a Paragraph because they are not contextually relevant. The proposed Settings and Styles split is something that should be consistent because it's relevant for almost every block and helps structure all the tools. The List View, however, is only relevant for a few blocks or a few situations (like locked patterns). Forcing that to be consistent will degrade the experience for the majority of the blocks that don't need it or don't have child blocks. The point about the sidebar being disconnected from the canvas in terms of being the main interface to edit is definitely a good concern. I think the issue is how this is being presented that is leading to confusions on the goals, though. It's important to have a more data view for editing menus and navigating sections of child blocks, but it should not replace in canvas editing or traversing. Also, it should be easy to go from the canvas / toolbar to the list view editing for those that need that input mode. A while back we used to have a list view button in the toolbar of the navigation block that would open a modal to edit — the design intention is to render this element in a dedicated sidebar panel instead of the modal, but it follows the same idea. ContentOnly patterns can also be edited in canvas, even if the sidebar provides an overview of the structure. The two things should be complementary. |
talldan
force-pushed
the
try/appearance-settings-tabs-in-sidebar
branch
from
8530a42 to
2990b61
Compare
scruffian
force-pushed
the
add/list-view-tab-to-sidebar
branch
from
4bda26d to
5675cf9
Compare
|
I rebased this now the parent branch is merged. |
talldan
force-pushed
the
add/list-view-tab-to-sidebar
branch
from
5675cf9 to
a81d704
Compare
|
The other idea I've had to around this issue is that the tabs become an optional preference. It would default to on, but turn it off and the inspector works the way it is in It would essentially be taking the experiment feature toggle that's currently implemented and converting it into a user preference. The negative aspects are that it would be a lot to maintain, and might hinder future iteration if at some point some tab specific UI is desired. 🤔 |
packages/block-editor/src/components/inspector-controls-tabs/list-view-tab.js
Outdated
Show resolved
Hide resolved
Switch editor sidebar icons to new drawer icons Icon should reflect RTL as well. Update TabPanel to allow icons on TabButtons Add menu group to InspectorControl slot fills Move nav menu controls into InspectorControls menu group Introduce menu, settings & appearance tabs to sidebar Refactor InspectorControlTabs Re-orders the appearance and settings tabs. Also now omits the TabPanel altogether if only a single tab has contents. Make block inspector tabs a Gutenberg experiment A little tidy up Clean up conditional tabs display Remove nav specific menu tab for now Remove Menu inspector controls group Refactor inspector controls tabs to components Remove conditional display of tabs Render no settings or tools messages when no fills Reduce new styles for equal width tabs Add general slot for items applying to block as a whole Move query block new post link to new slot Revert "Move query block new post link to new slot" This reverts commit 1279985. Revert "Add general slot for items applying to block as a whole" This reverts commit 186276f. Tweak no style options message Add changelog for TabPanel updates Remove empty readme until experiment settles Fix copy and paste error Provide list view tab and slot for nav block
scruffian
force-pushed
the
add/list-view-tab-to-sidebar
branch
from
a81d704 to
bfb850a
Compare
Related:
What?
Adds a new "List View" tab to the sidebar and if the block inspector tabs experiment is enabled, renders the Navigation block's menu controls to that tab.
Why?
How?
Important Notes
Testing Instructions
Screenshots or screencast