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

Current block invisible focus when Unified Toolbar is on #10559

Closed
Ryokuhi opened this issue Oct 12, 2018 · 11 comments
Closed

Current block invisible focus when Unified Toolbar is on #10559

Ryokuhi opened this issue Oct 12, 2018 · 11 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@Ryokuhi
Copy link

Ryokuhi commented Oct 12, 2018

Describe the bug
When the Unified Toolbar is active, the focused block is not outlined.

To Reproduce
Steps to reproduce the behavior:

  1. Activate Unified Toolbar
  2. Focus a block
  3. No outline is shown around the block

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.
unified toolbar on
unified toolbar off

Desktop (please complete the following information):

  • OS: Windows 10 Home
  • Browser & Version: Chrome 69.0.3497.100
  • Browser & Version: Firefox 62.0.3

Additional context

  • Gutenberg Version: 3.9 on local, Version 4.0.0-rc.1 on frontenberg
@mtias
Copy link
Member

mtias commented Oct 12, 2018

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.

@mtias mtias closed this as completed Oct 12, 2018
@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Oct 16, 2018
@afercia
Copy link
Contributor

afercia commented Oct 16, 2018

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):

Moving the toolbar at the top should be possible also for users who don't want this "lighter" UI.

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.

@afercia afercia reopened this Oct 16, 2018
@mtias
Copy link
Member

mtias commented Oct 16, 2018

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.

@mtias mtias closed this as completed Oct 16, 2018
@afercia
Copy link
Contributor

afercia commented Oct 16, 2018

Feedback was heard, doesn't mean it has to be agreed upon.

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.

@spencerfinnell
Copy link

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.

@joedolson
Copy link
Contributor

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.)

@afercia
Copy link
Contributor

afercia commented Nov 9, 2018

Reopening, as agreed during today's accessibility meeting and @joedolson doesn't have the powers to reopen issues.

@mtias
Copy link
Member

mtias commented Nov 12, 2018

@afercia @joedolson these outlines have shown to be problematic in both modes. I suggest removing them from :hover across the board and keeping them for focus/selection only. Let me know what you think.

@dottxado
Copy link

@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?

@mtias
Copy link
Member

mtias commented Nov 19, 2018

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:

image

@spencerfinnell
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

No branches or pull requests

6 participants