-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Better differentiate visually actionable texts in Table/Column sidebar #1245
Comments
@manuhabitela , I see several changes from the current product in the mocks:
Are these enough to address the issue described (differentiating actionable texts)? The green links still look just like dark-grey text to a color-blind person (no border/shadow/underline), so I wanted to double check. |
For this specific issue, I'm only talking about the buttons like "open row styles" or "set trigger formula". The suggested changes in the mockups are:
I'd argue these changes are enough, especially with the font-weight one! But I see your point about my previous example, the color change does not solve the fact that, when having trouble distinguishing colors, I wouldn't notice the difference between black labels and green actions by color. We can argue the fact that now that their font-weight is different, in addition to their position in the UI, the text that is explicit that those are actions, and the different case (labels are uppercase), this is all enough to prevent any questioning. [1] This is related to a recurring question specific to a dense UI like Grist. If we want to follow all WCAG rules by heart, sometimes, we could argue UI would be too cluttered, too heavy on the eye, for most people. That's why we can decide to have an "accessibility mode" (or a "high contrast mode", you get the idea), that we could enable in theme settings. This lets us have a UI that is globally very "pronounced" for people needing it when enabling accessibility mode. While still making changes that will help everyone in the default UI, but sometimes not 100% checking WCAG criteria. For example Lucie decided to do that for the darker border on inputs. We change them for the default UI because for now they are really, really light, making unchecked checkboxes easily not noticeable for lots of people. But the color change doesn't match the WCAG criteria because she concluded this would be "too much" if applying it on every input border by default, in such a dense UI. So we plan for the accessibility mode that would have those borders even more contrasted, with WCAG-compliant colors, so that people having visual impairments can understand everything without any doubt. Would that work for you? |
Yes, that answers my question. Thanks! |
Describe the problem to be solved
This is related to #1243 but I figured creating a detailed issue for this case would be better. Please go check this related issue to understand the context.
The specific problem here relates to all the clickable, green colored texts, that act as buttons without looking like ones, visible mostly in the Table/Column sidebar:
These are problematic because the color can easily be missed by people with disabilities.
To give an idea, here if I simulate a view of someone having achromatopsia thanks to Firefox devtools, you get the point:
Describe the solution you would like
We could argue the problem is not a very big one because the labels are pretty explicit. But it would be better to not rely on color only to show that those texts are interactive. Or, if relying on color only, to use a color that is more contrasted with the usual black text color, so that they can be noticed even with visual impairment.
The text was updated successfully, but these errors were encountered: