-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Current block invisible focus when Unified Toolbar is on #10559
Comments
Thanks for the report. This is an intentional design choice, as the idea behind "Unified Toolbar" is for people that don't need the visual connection of blocks and their tools, and would prefer a more traditional text editing canvas. |
I was unaware this issue was opened and seems to me the design intent here is based on a wide assumption. Also noting this design choice affects accessibility and no accessibility feedback was asked. As noted for a similar issue in #9334 (comment) the Unified toolbar shouldn't make the UI lighter. It should just do what it says: unify the toolbars at the top. If users want a lighter UI, there's Spotlight mode for that. For example, as an user with low vision of other vision impairments or even without any impairment, I might prefer the Unified toolbar. Still, I might want to have a clear indication of focus and a clear indication of what the selected block is. Pairing Unified Toolbar with features that should go in Spotlight mode is not ideal for accessibility. I'd tend to think the best approach would be just giving users the options to set the UI in the way they prefer, without unintended effects. Coincidentally, a11y feedback was given in #9334 (comment):
I would have expected that feedback was taken into consideration or, at least, discussed. Reopening for consideration. Please direct further requests for clarification and feedback to the a11y team. Thank you. |
Feedback was heard, doesn't mean it has to be agreed upon. "Unified Toolbar" (it's a terrible name) is meant to give a traditional writing environment where focus is signaled by the blinking cursor on text or the internal selection state of inputs, galleries, etc, for other blocks. I might agree that we could allow the outline to show on the selected block alone (not on hover, for example, as the default view), and I'd be happy to check a PR that proposes such a change, but I need a more persuasive argument — that a block needs the outline for selection purposes doesn't go without saying. |
Not so fair, as this editor is supposed to be accessible and WCAG compliant. 🙂Fair enough., just one of the many details that contribute to make it not accessible. Thank you for your clarification. |
The name "Unified Toolbar" makes this feel like a bug when toggling between the toolbar types. If the toolbar is not the only thing being affected the name should change. I would expect only the toolbar position to change based on the current name. I thought something was broken in master until I found this issue when I could no longer see any selection indicators. |
Looking at this issue, I think that the labeling "Unified Toolbar" gives the clear impression that the only change will be to how the toolbar behaves, and Spotlight Mode indicates it will change how the block focus will change. Regardless of the accessibility issues with focus, I think that these controls should only change the specific items they describe, and not also impact other behaviors - that's confusing, and makes it more difficult to configure the design the way you want. Right now, you cannot configure an option that keeps focus outlines but uses the unified toolbar. If enabling the unified toolbar kept the focus outlines, you'd still be able to remove them using the spotlight mode. In short: the Unified Toolbar should not remove outlines, as that reduces the number of choices available to the user without reducing the number of controls. (I'm fine with having fewer options for the user, but only if it means a simpler interface with fewer controls.) |
Reopening, as agreed during today's accessibility meeting and @joedolson doesn't have the powers to reopen issues. |
@afercia @joedolson these outlines have shown to be problematic in both modes. I suggest removing them from |
@mtias I'm at Accessibility table at Contributor Day Milano, and we are evaluating this issue. Can you please explain why the outlines have shown to be problematic? For what we can evaluate, the hover is useful in a lot of cases. I have some projects with lots of custom blocks, and the hover on the block (also with the name in the label on the right), is useful for my customers that want the "unified toolbar" to work as expected only unifying the toolbar :) @enricobattocchi @marcochiesi what do you think? |
Hi @dottxado, thanks for chiming in. The feedback has been mostly of the form "there is too much going on when I move the pointer and I get confused". Note that the labels do appear on hover, it's just the outlines that are removed. Particularly the case where multiple elements have outlines and sense of placement can be compromised: |
I can certainly see how there is visual overload but the floating labels with no context (visually they are attached to nothing) is even more confusing. At no point when using the previous iteration of the Unifed Toolbar did I think everything was working correctly. It seemed and felt broken. I agree with the idea in the PR of switching the hover outline and selected outline. |
Describe the bug
When the Unified Toolbar is active, the focused block is not outlined.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
As when the Unified Toolbar isn't active, an outline border around the current focused block should be visible.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: