glpi-project
Remove lowered opacities for some forms UI
Checklist before requesting a review
- [x] I have read the CONTRIBUTING document.
- [x] I have performed a self-review of my code.
Description
50% opacity for elements can be an accessibility issue when we expect the elements to still be interactive.
This is very easy to see when using the accessibility options in the Rendering tab of the Chrome dev tools.
Reduced contrast vision deficiencies emulation:
The toggle to enable direct access is completely invisible for me with the vision deficiency emulation.
Also, for the Service Catalog tab for KB items it isn't immediately obvious why the tab gets faded out when the article is in the service catalog; Nothing is disabled.
If there are other suggestions for conveying some meanings these locations, I am open to making those changes here.
I agree opacity may not be a correct solution; but we still need an indication this is inactive (if it's not yet, I did not test).
What about simply using the @media (prefers-contrast: more) { media query to always set the opacity to 1 ?
This way it should only change things for users that explicitly request higher contrast.
What about simply using the
@media (prefers-contrast: more) {media query to always set the opacity to 1 ? This way it should only change things for users that explicitly request higher contrast.
I agree with @orthagh suggestion to hide the sections when they don't apply. We don't change the opacity for disabled/irrelevant sections anywhere else in GLPI AFAIK. Relying on the contract preference and opacity would be different UX and I am not aware of any other things in GLPI, Tabler or Bootstrap that change based on that preference. I would prefer having acceptable contrast levels as the default experience.
I'm still not sure overall, it make the feature move convenient for a small subset of users while making it less convenient for the majority of users.
I would prefer a solution where both types of users "win".
I'm still not sure overall, it make the feature move convenient for a small subset of users while making it less convenient for the majority of users.
I would prefer a solution where both types of users "win".
There are too many factors that affect the usability of functional/interactable elements with high transparency.
- A user with slightly reduced vision but not enough to warrant special settings/tools in other cases may have trouble seeing it.
- Elements may be less visible based on GLPI theme. In light theme I have a much harder time seeing them.
- A screen with slightly reduced brightness or contrast may make them difficult to see. I've already had this where my monitor had slightly reduced brightness and I couldn't tell the difference between some white/gray backgrounds in GLPI but never noticed any usability issues elsewhere.
I would prefer to see GLPI accessible by default unless there is some measure that adds a significant block for other users. Hiding options behind a toggle that needs enabled anyways for the options to have an effect doesn't seem like an extraordinary block to me.
I don't disagree with your main statement which is that the current state is not accessible enough, I'm just not sold on hiding things as it goes against discoverability which is often a big UX concern.
Accessibility rules states that there are no contrast requirement for parts of the UI that refer to an inactive module:
So maybe if we remove the lowered opacity for the label + control while keeping it for the "sub form" then we are compliant while keeping a better discoverability for most users ?
So maybe if we remove the lowered opacity for the label + control while keeping it for the "sub form" then we are compliant while keeping a better discoverability for most users ?
That was one thing I originally considered but it isn't really done like that anywhere else in GLPI. When we have sections of options that only apply when some other setting is enabled, we either always show the extra options or only show them when the main option is enabled/the right value (SNMP credentials for example). We don't use transparency AFAIK to indicate non-applicable sections. Even for disabled components, the labels remain the regular opacity and the fields are more grayed out than trasparent.
So maybe if we remove the lowered opacity for the label + control while keeping it for the "sub form" then we are compliant while keeping a better discoverability for most users ?
My 2 cents, I would be OK with that
... anywhere else in GLPI
While I agree with the general sentiment of that, where general controls/displays should be generalized or not differs too much.
On this particular page, considered as a "new" feature and where we precisely explore new UX options, I think we can ease a bit the need to format as the rest of GLPI.
More, if we agree to improve both UX and accessibility with the proposed @media attribute, I think we can expand later (post 11 release) the design to the other components you listed above.
On this particular page, considered as a "new" feature and where we precisely explore new UX options, I think we can ease a bit the need to format as the rest of GLPI.
I agree that new types of UI components may look different, but this type of form, with sections that may not apply, isn't really new.
Having different user experiences in new feature areas without a clear design goal for all of GLPI is going to make it difficult to standardize the look and feel later.
More, if we agree to improve both UX and accessibility with the proposed
@mediaattribute, I think we can expand later (post 11 release) the design to the other components you listed above.
I think broad usage of "prefers-contrast" is a bad idea. It is much simpler to just have proper contrast as a baseline. For "prefers-reduced-motion" it at least makes a little sense that we would want animations in some cases by default.
GLPI's styles are already complex with our palettes based on our styles based on Tabler which is finally based on Bootstrap. Managing high contrast adds another layer of complexity.
Also, in general I don't have issues with the contrast of elements in GLPI as it is now but this particular UI causes me some trouble in certain circumstances (light theme, monitor settings, environment light).