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

Make always-visible block icon accessible and usable #11669

Closed
chrisvanpatten opened this issue Nov 9, 2018 · 9 comments
Closed

Make always-visible block icon accessible and usable #11669

chrisvanpatten opened this issue Nov 9, 2018 · 9 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback.
Milestone

Comments

@chrisvanpatten
Copy link
Contributor

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

48197149-ba743e00-e34c-11e8-8d83-581bceffe379

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?

@chrisvanpatten chrisvanpatten added Needs Accessibility Feedback Need input from accessibility [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. labels Nov 9, 2018
@afercia
Copy link
Contributor

afercia commented Nov 9, 2018

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

Good question.

@afercia
Copy link
Contributor

afercia commented Nov 19, 2018

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

@afercia afercia removed the Needs Accessibility Feedback Need input from accessibility label Nov 19, 2018
@catehstn catehstn added the Needs Design Feedback Needs general design feedback. label Nov 19, 2018
@catehstn catehstn added this to the WordPress 5.0.x Follow Ups milestone Nov 19, 2018
@timwright12
Copy link
Contributor

@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
Copy link
Contributor

afercia commented Dec 1, 2018

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:

screenshot 2018-12-01 at 14 57 15

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

@timwright12
Copy link
Contributor

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

@chrisvanpatten
Copy link
Contributor Author

chrisvanpatten commented Jan 23, 2019

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
Copy link
Contributor

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
Copy link
Contributor Author

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

jasmussen pushed a commit that referenced this issue Feb 7, 2019
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?
jasmussen added a commit that referenced this issue Feb 12, 2019
* 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.
youknowriad pushed a commit that referenced this issue Mar 6, 2019
* 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.
youknowriad pushed a commit that referenced this issue Mar 6, 2019
* 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.
@mapk
Copy link
Contributor

mapk commented Apr 5, 2019

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

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). General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

No branches or pull requests

7 participants