-
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
Make always-visible block icon accessible and usable #11669
Comments
Good question. |
Removing the "Needs Accessibility Feedback" label, as feedback is implied in the comment above. |
@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 What about converting block icons that don't have menus into Thoughts? |
I'd agree it should be purely decorative, e.g. a One more problem with this disabled button is that it uses an aria-label (reminder: when using a screen reader it is possible to navigate through all content, not only focusable elements) |
I can probably tackle this later in the week (via @10up) |
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 :( |
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? |
@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. |
This one goes out to all the @chrivanpatten's in the crowd! Well, specifically, it is in response to this conversation we had here: #11669 (comment) The problem: we always show the Block Switcher interface, even if no transformations are available. When no transformations are available, the buttonis _disabled_, which usually means it needs to have very contrast. However in this case, the block switcher also works as a block type indicator, which makes it valuable to be able to see the icon in question. This PR tries to marry the two challenges and shows the button as disabled adding a light gray background, but still increasing the opacity. Thoughts?
* Try: Show background and increased opacity on disabled switcher This one goes out to all the @chrivanpatten's in the crowd! Well, specifically, it is in response to this conversation we had here: #11669 (comment) The problem: we always show the Block Switcher interface, even if no transformations are available. When no transformations are available, the buttonis _disabled_, which usually means it needs to have very contrast. However in this case, the block switcher also works as a block type indicator, which makes it valuable to be able to see the icon in question. This PR tries to marry the two challenges and shows the button as disabled adding a light gray background, but still increasing the opacity. Thoughts? * Try darker gray and monochrome icon.
* Try: Show background and increased opacity on disabled switcher This one goes out to all the @chrivanpatten's in the crowd! Well, specifically, it is in response to this conversation we had here: #11669 (comment) The problem: we always show the Block Switcher interface, even if no transformations are available. When no transformations are available, the buttonis _disabled_, which usually means it needs to have very contrast. However in this case, the block switcher also works as a block type indicator, which makes it valuable to be able to see the icon in question. This PR tries to marry the two challenges and shows the button as disabled adding a light gray background, but still increasing the opacity. Thoughts? * Try darker gray and monochrome icon.
* Try: Show background and increased opacity on disabled switcher This one goes out to all the @chrivanpatten's in the crowd! Well, specifically, it is in response to this conversation we had here: #11669 (comment) The problem: we always show the Block Switcher interface, even if no transformations are available. When no transformations are available, the buttonis _disabled_, which usually means it needs to have very contrast. However in this case, the block switcher also works as a block type indicator, which makes it valuable to be able to see the icon in question. This PR tries to marry the two challenges and shows the button as disabled adding a light gray background, but still increasing the opacity. Thoughts? * Try darker gray and monochrome icon.
Looks like this is fixed with #13721 so closing. If I missed anything, we can always reopen it. |
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:
Fundamentally, what's the point of always showing the icon if a certain subset of users can't see it?
The text was updated successfully, but these errors were encountered: