lmms
lmms copied to clipboard
LMMS
A few CSS tweaks for better accessibility
fixes: #7078 #4464
I have solved a few issues related to accessibility with this PR. Need advice on better color schemes. Here's the new styling options in action (excuse the broken theme of obs):
https://github.com/LMMS/lmms/assets/74815851/059e3e50-129b-4b01-8a47-de8cf27d34de
@musikBear wanna add anything to this?
Scrollbar looks good! It is now possible to see it, that is actually a good thing : p
But should a 'No'-button have green outline?
I get that the color-outline shows the button that has focus, but at the same time green means 'yes', whereas red or orange means 'stop or reject'.
Intuitively a lot of users would react to the color rather than reading the text on the button.
..Idk -that one is a bit tricky ..
I would like to hear what others think about green on 'No-buttons'
Thanks for the feedback.
For the green No button, i felt something was off too. Now that you said it, i get what's wrong. Would changing it to white suffice?
I'm in support of any changes that help with accessibility without causing issues for eye strain. If we are going to change the scroll bar colors to almost white, does it need a green tint? I'm pretty sure we can use the same value and lightness and change the hue to match the gray.
I understand the comment to use the standard LMMS green for consistency, but using a darker green will just bring us back to the starting point where it's a darker value and reduce contrast again. So it might work better to focus on an off-white with the same hue as the gray IMO.
Tbh the green tint was accidental, me being stupid with color selection. I will change this to off-white,+ hover can use standard lightgreen i think.
Would changing it to white suffice?
Yes i think that would be intuitively neutral, and then the text on the button would be focused by users.
Other programs uses a blue outline like
or
Blue is perhaps an indicator of attention?
White may look 'boring / indifferent' whereas blue indicate that the outline is pr design. The blue shade need to be light, else it will disappear in dark gray background.
Something like
@musikBear I want to summarize my points so it will be lacking a bit of nuance because I want to avoid going down a rabbit hole on this one.
The themes you sent screenshots of use blue as the default primary color, which is the most common primary color to be used. In the case of LMMS, the primary color is green.
It's better if we don't add a new bright color in a place people don't expect it, which will start to break other UI rules to fix the issue if there are solutions which will not cause any problems or debates.
To center back on the goal at hand here, we are looking at how to increase contrast to help with accessibility. When green is used to border the "no" button it causes some potential confusion.
White fixes this confusion and does not introduce a new color. A conditional red on all no buttons would fix this as well. Blue does not since it's still an active indicator and does not provide any further clarity
I'm not opposed to experimenting so if anyone really wants to try the blue, please use the matching blue I the theme palette and we can compare the options at once to come to a final conclusion👍
I have fixed all your concerns and have posted an update in the main PR body. Anything else?
I have looked at the classic theme too, looks like 2 of 3 issues addressed here are not there in classic theme. I will fix the third issue (button focus) now, will use black there.
~~With regards to my personal taste the slight green somehow "bites" with the other colors. Here's a screenshot of the scroll bar next to the piano:~~
~~I think in this case it would be better if the color of the scroll bar would be pure bright gray with no color tints.~~
Edit: Forgot to pull after the fetch and used an old branch.
Didn't i change that one to white?
Nevermind. I did fetch your changes but it did not pull the branch which I already had checked out previously. So I saw some old state after I had built again.
Last thing that I'd personally change is to remove the outline when the scroll bar is being moved because it somehow clashes with the flat look IMO.
I wanted to have some indication of the taskbar being moved. If there's any better way to indicate, please tell me. I'm all open for suggestions.
@Rossmaxx If we change the scroll bar to off-white with a gray tint, we will have room to use a pure white as the active color when it's moving. This will work because pure white causes eye strain if it's present for a long time so using it only when active might balance it out.
@RebeccaDeField i have added white to pressed mode, and also added black border for hover.
With the border it now feels strange to me when interacting with it. Almost as if it ducks away or does not want to be interacted with:
Screencast_20240414_173854.webm
Personally I'd get rid of the border changes and just use the full flat scroll bar with different colors in the different modes.
Personally I'd get rid of the border changes and just use the full flat scroll bar with different colors in the different modes.
After seeing the video, yeah I think no border would be best. The non-hover color looks good, maybe on hover change it to the green hue as seen in https://github.com/LMMS/lmms/pull/7202#issuecomment-2053572939 ?
I have commented out the hover effect for now. For some reason, I don't want to add that greenish white rn.
If it's ok, i will remove it in the next commit
Looks good to me now. Personally I wouldn't add the greenish white either.
One last option would be to change the hover color to something between the "passive" gray and the "move indicator" white to indicate that the scroll bar would interact when being clicked. But that's not super important IMO and I also don't want to drive @Rossmaxx insane with all the little requests. :wink:
Ok. I'm proceeding with removing the hover effect for now. If the need arises, someone can add it.
Personally, i lean more and more towards a separate fully-accessible theme.
The change isn't bad on its own, but it just doesn't fit.
Look at this screenshot: with the new color, the scrollbars are too prominent and attention-stealing, making me lose focus on what i would actually be doing instead, cause my eyes are easily caught by the brightness and contrast difference when moving across anywhere in the UI. I generally feel like it would cause me eye strain while using the program.
This is easily noticeable just by opening the pianoroll
The add effect button also feels weird and less clickable now:
Steps to reproduce:
- click on add effect -> button color changes while opening the window
- click on cancel -> the button color doesn't reset, and the only way to reset it is to click something inside the effect chain box, otherwise it's now inverted
The Add Mixer button is also kind of affected. The hovered state is kept and it feels way less clickable.
Note that this behaviours might be actually in the current nightly as well, it's just way more noticeable now.
These changes are also pretty drastic compared to what it's currently in the UI: buttons jump from a soft gray gradient to a full flat bordered surface which also bledns someway with the background
| Normal | Pressed |
|---|---|
I appreciate your comment but what else should i do to fix for the default theme then?
Personally, i lean more and more towards a separate fully-accessible theme.
The change isn't bad on its own, but it just doesn't fit.
I agree. But then one issue for one visually impaired isn't necessarily the same for another so that would mean the same discussions happening over and over again (for different sorts of color blindness, etc.). Isn't there visual aids to help 'tune' peoples colors/contrast and whatnot centrally on the desktop?
I appreciate your comment but what else should i do to fix for the default theme then?
It's just my opinion, doesn't mean it's absolute truth, i'm looking towards if anyone has the same feeling.
About what can it be done, Discord itself recently did something for accessibility and their scrollbars are still not that visible. That's why i said i lean towards having a separate theme for these concerns.
The default state of scrollbar on the default theme is very low contrast and that's true. But that's way too big of a jump anyways imo.
Even just using the current hover color as the default color, and then a higher brightness gray shade for when it's pressed would be a major improvement, without being that much invasive.
| Current default | Default with current hover |
|---|---|
Actually, i think it could also go a little further up in brightness, but definitely not as much as it was done as of now.
About the buttons, i didn't feel like they were not that accessible to begin with. It seems like the weird behaviour is non-existent in 1.2.2 stable tho, so that's been introduced, if not here, anywhere in 1.3.
#4464 despite being mentioned has a way different meaning to what was implemented here.
About the dialog buttons, i'd just make one of the 2 darker, i guess.
Personally, i lean more and more towards a separate fully-accessible theme. The change isn't bad on its own, but it just doesn't fit.
I agree. But then one issue for one visually impaired isn't necessarily the same for another so that would mean the same discussions happening over and over again (for different sorts of color blindness, etc.). Isn't there visual aids to help 'tune' peoples colors/contrast and whatnot centrally on the desktop?
I'd love to be able to answer, but i'm really no professional designer, and not being visually impaired (at least i think so) myself, doesn't really give me a better understanding. All i know it's that usually most visually impaired people prioritized more contrasty stuff cause it's clearer to them. But that's most, as you said visually impaired actually has multiple derivations.
That said, the same thing would apply in this PR: if one issue for one visually impaired isn't necessarily the same for another, what exactly are we fixing here?
The add effect button also feels weird and less clickable now:
Steps to reproduce:
* click on add effect -> button color changes while opening the window * click on cancel -> the button color doesn't reset, and the only way to reset it is to click something inside the effect chain box, otherwise it's now invertedThe Add Mixer button is also kind of affected. The hovered state is kept and it feels way less clickable.
Note that this behaviours might be actually in the current nightly as well, it's just way more noticeable now.
I can reproduce this. This is caused by the new QPushButton:focus entry in the style sheets. I think the following happens:
- The "Add effect" button is clicked. This gives it focus but it is immediately transferred to the effect selection dialog.
- The dialog is closed via "Cancel".
- Qt now checks if it should give the focus back to something else and this is the "Add effect" button that was clicked before.
As long as nothing else gets focus the button stays in that state.
Same with the "Add mixer channel" button. Nothing else gets focus after it was clicked and thus it stays in that state. One might now wonder if in that case the focus should be given to the new mixer channel because users want to interact with that new channel. However, it might also be that users wants to add several mixer channels and in that case it would be good if the "Add" button keeps focus because the users can then simply repeatedly hit the space bar to add more channels.
Logically the same happens in the current master without the changes but because there is no style sheet entry for push buttons with focus this is not noticeable.
So what exactly is the fix for the push button focus issue, other than removing the css option @michaelgregorius ?