Make always-visible block icon accessible and usable

[chrisvanpatten]

In #11600, we made the UI always show the block icon.

However it's being displayed in a low opacity state, with the idea being that it's not an active button like the block type switcher.

However, I would argue that in this case, the icon is serving an entirely different purpose than the block switcher button: it's a visual label, which helps indicate/reinforce the current block.

Removing the dropdown arrow changes the context of the icon entirely. Lowering the opacity, as a way of further reinforcing a disabled state, makes the icon inaccessible as a visual aid for indicating the current block.

Further, I would argue that it sends a confusing message. The dimmed block icon can be easily interpreted as a reflection of the block's own state, suggesting the block itself is disabled.

I have a few potential ideas:

1. Simply show the block icon at full opacity, without the dropdown icon
2. Include the full switcher, and make the switcher icon appear visually disabled when hovered
3. Continue using the low opacity but still include the dropdown arrow so it's clearer that it's the dropdown UI that's disabled, not the block in some way
4. Separate the block icon and switcher into two toolbar buttons, only showing the switcher icon when it has available options, and always showing the block icon at full opacity

Fundamentally, what's the point of always showing the icon if a certain subset of users can't see it?

[afercia]

Fundamentally, what's the point of always showing the icon if a certain subset of users can't see it?

Good question.

[afercia]

Removing the "Needs Accessibility Feedback" label, as feedback is implied in the comment above.

[timwright12]

@chrisvanpatten @afercia This is an interesting one, for sure. If we enable the button (which is currently how we're controlling the opacity), then we have an active button in the UI that doesn't do anything. If we make an exception for these specific types of disabled buttons, I feel like that doesn't quite solve the problem. I briefly testing with role="presentation" on the button, but that didn't seem to work.

What about converting block icons that don't have menus into <div>s or <span>s so they act more like iconography? It seems like some styling might need to be updated, but overall it might more directly address the issue.

Thoughts?

[afercia]

I'd agree it should be purely decorative, e.g. a <span> and it shouldn't be wrapped in a <Toolbar> component.

One more problem with this disabled button is that it uses an aria-label Block icon which doesn't tell anything meaningful to users:

(reminder: when using a screen reader it is possible to navigate through all content, not only focusable elements)

[timwright12]

I can probably tackle this later in the week (via @10up)

[chrisvanpatten]

This is still driving me batty. I'm relatively well-sighted (with an assist from glasses, shoutout to glasses 😎) and still have trouble seeing this icon at certain points, under certain lighting conditions, screen brightness changes, etc.

@jasmussen Curious if you have any ideas to iterate this to improve visibility under different conditions? In the wrong environment it just looks like a weird blank space, and the UX benefits of providing the icon are decimated :(

[jasmussen]

Curious if you have any ideas to iterate this to improve visibility under different conditions?

The opacity is due to it being disabled. But we can consider a different disabled state here, perhaps where the opacity of the icon is higher and monochrome (i.e. desaturate all icons), and with a light gray background?

[chrisvanpatten]

@jasmussen Yeah, I think that would be helpful. I understand the intent but since block authors can change icon colors it can lead to situations where we can't guarantee the icon is appropriately visible (e.g. a low opacity black will be very different from grey at the same low opacity).

Taking control of the icon color in disabled states would be a great way to overcome this problem.

[mapk]

Looks like this is fixed with #13721 so closing. If I missed anything, we can always reopen it.