A few CSS tweaks for better accessibility

[Rossmaxx]

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):

obs-recording-2024-05-19-16-54.mp4

[Rossmaxx]

@musikBear wanna add anything to this?

[Rossmaxx]

Inviting @RebeccaDeField for review

[musikBear]

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

[Rossmaxx]

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?

[RebeccaDeField]

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.

[Rossmaxx]

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.

[musikBear]

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

[Rossmaxx]

Noted the blue colour. Will post updates once i get back on pc.

[RebeccaDeField]

@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

[RebeccaDeField]

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👍

[Rossmaxx]

I have fixed all your concerns and have posted an update in the main PR body. Anything else?

[Rossmaxx]

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.

[michaelgregorius]

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.

[Rossmaxx]

Didn't i change that one to white?

[michaelgregorius]

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.

[Rossmaxx]

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.

[RebeccaDeField]

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

[Rossmaxx]

@RebeccaDeField i have added white to pressed mode, and also added black border for hover.

[michaelgregorius]

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.

[RoxasKH]

@musikBear Re: scrollbars: Does it satisfy accessibility requirements if it's only bright on hover?

No, it is hard to find the handle on the bar, eg seeing where the handle is, that is the issue. After grabbing the handle it is not important if it has a contrasting shading, but simply spotting it, is where the real visual issue lies.

Yeah I can see the problem. Most interfaces hide them entirely until they're used, which I would expect is in the extreme wrong direction.

I took a look at GarageBand -- for example -- and it's so gesture-focused, you can't even get the bottom scrollbar to appear unless you hit an arrow key on the keyboard or have an input device capable of moving the editor left/right.

Oddly, Apple calls this an "Appearance" feature, not an accessibility feature; probably because all of their "official" pointing device support gestures.
With this toggled, it's pretty noticeable. I'm not sure if this information helps the average LMMS user though; trackpads and gestures are still a bit of a Mac-ism, which doesn't represent our average end-user.

That said, I'm curious if the contrast offered by GarageBand pictured below is suitable. If so, it maybe a matter of compromise as @RoxasKH has alluded to above. If we wish for this to to be resolved quickly, I believe @musikBear and @RoxasKH should agree, as it will allow this PR to get merged and the software to be more usable. I disagree strongly of any sentiments this fix needs to wait behind an overhauled accessibility update. It's a small, reasonable request and it can be fixed and closed quickly if parties can agree. <3

Changes on the scrollbar are good, they just went too far. Imo using the current hover as default and a brighter shade for hover as usual would be a good way to go, and it should already make it stand more and be more findable. As i said it can probably be cranked up even a bit more, although i'd like to avoid getting flashbanged on the hover state personally. The current default theme was already designed to have a decent amount of contrast and scrollbars might need a bit more but not too much imo.

Obviously this might not be enough for people with serious visual issues. That said i still think that has to be accomplished with separate themes. There's no in between where visual impaired people completely enjoy one theme and everyone else does too. Some might even find the default theme too contrasty.
The default theme should be a good common neutral entry point, and the program should have more options for those who doesn't find comfortable in it.
Windows itself uses different themes for their apps: https://learn.microsoft.com/en-us/windows/apps/design/accessibility/high-contrast-themes
Cause that's the longer but more solid path. Everyone gets what they need, contrast party or eye relaxing schemes.

You could even just pump up contrast on your own monitor. There's many layers of accessibility support to IT.

About the buttons, it would need some more thinking but as i said i wouldn't change them completely cause that's a big bump and ruin consistency. You could probably just change the border color with something suitable, or make the whole selected button similar to the non-selected one but with shades of green. I do believe that this shouldn't extend to the Mixer and cause the issues that were introduced with the additional css selectors.

There's no need to go drastic just for accessibility's sake. I'm not sure how much am i a fan of them, but here's a couple of quickly drafted option that take inspiration from other programs, one just changes the selectede button color, the other uses an outer border to give a dvisual difference both in colors and perceived size

Colored	Border

In the border one, bg color might also gets a little darker, but it should keep the gradient and shouldn't reach the point where it blends in to the background.

Honestly speaking as custom themes as of now are a possibility, i believe there should be a third party effort for the time being for accessible themes. It's not like i have anything against visual impaired people, but i do believe that LMMS has way major flaws to deal with (both in core and UI, like making the UI scalable, dpi support and switch all the images to svgs or some other vector type) before dealing with these kind of stuff (it's also kind of wiser cause you don't have to remake the theme as often once the UI is stable enough).
That said if anyone comes up and wanna work on an accessible theme as this is a community project is probably more than welcomed. Personally i don't have enough knowledge about this kind of accessibilty stuff to make one. I don't even have some kind of UI/design expertise, i'm just an amateur that like modern UIs and base itself on what he uses daily.

Reading online, it doesn't look like too many DAWs are accessible.
That said, this is obviously not something that should stop LMMS from being accessible.

[tresf]

believe there should be a third party effort for the time being for accessible themes. I

This proposal solves nothing here. There's no 3rd parties, there's only 1st parties. Let's stop this rhetoric please. <3

[RoxasKH]

This proposal solves nothing here. There's no 3rd parties, there's only 1st parties. Let's stop this rhetoric please. <3

Agreeable, then the option left imo should be an official effort to a default accessible theme. That does mean having someone competent enough willing to contribute for such a theme and hopefully keeping it updated with lmms changes. The coolest part is that, just like for everything in a community maintained project, this solves nothing just like the rhetoric until the requirement isn’t fulfilled.

I really do believe that there’s no inbetween field that would make every side happy. I don’t know many people that aren’t visually impaired using contrast theme options on windows only because it looks cool. While they surely exist, the default theme should aim at covering the basics for most people the best it can. Otherwise its a dog chasing its tail, we might get drastic changes for visually impaired people in just to get complaints from non visually impaired people afterwards and going on circularly.

To be noted that this doesn’t mean this pr/issues shouldn’t be covered: the default theme definitely lacks some contrast in those sections, and they can be improved, I’d just try to keep it consistent, a scroll bar is a very generic component and doesn’t have to stand to the eyes over other elements in a much more complicated Ui that would benefit from accents elsewhere. Hopefully me and other people gave some ideas that can be used as a trace to follow

Just to make clearer what I meant: community effort obviously means little and it could also never get an accessible theme, but I was saying that while LMMS takes its time to get an official one, that’s probably where to take a look at. I didn’t mean to say LMMS shouldn’t address accessibility concerns, although I do believe that basic usability it’s on a higher priority level and more likely to get contributions.
Correct me if I’m wrong, but afaik the current default theme itself comes from community effort translated and refined into official afterwards, so an accessible official theme could also follow a similar path, who knows.

Ps side note: the colored button proposal was also mentioned about making the loop state more evident in #3069 , where Rebecca also proposed a darker background/green icon mock-up that could also apply as a possible option here too.

[tresf]

I'll try to make this as simple as possible:

• @musikBear: pass/fail
• @RoxasKH: cosmetic approval
• @RebeccaDeField: final say

If this can happen, we can fix this issue. Anything more is out of scope. This issue has three problems to solve, they should be the focus: #7078, #6047, #4464. We have a dev willing to do this, now, so let's please band together and take advantage of that.

[RebeccaDeField]

@RoxasKH I appreciate where you're coming from, but I'd like add a points to contrast some of the comments from myself years ago as I was a much less experienced designer when I headed the theme efforts up and my perspective has changed quite a bit.

When it comes to "accessibility" I think the idea of creating a complete alternate theme might misunderstand the major audience that needs it. This doesn't refer to people with major vision impairment, but also the evergrowing population of people who just don't see 20/20 without glasses. The idea to make the theme usable for a wide range of vision types means that this covers not just a minority but a major percentage of users all with different slight challenges. This is something that behind the scenes of existing software development, we will see major changes in waves soon due to understanding this better.

So if we can live with a slightly brighter scroll bar and still focus on using the program to do what it was made to do, and a large percentage of the users don't have to click around trying to find it then I see this as a win.

We can tone down the brightness ever-slightly to reach a compromise and then move forward with it. If we receive a lot of complaints or requests due to the brightness being too much we can tone it down further but I think debating between a few people won't be a good indicator of whether it will even be noticed or cause problems for the overall audience.

These bright yellow sidewalk entry markings are not reserved for a separated sidewalk because the rest of us can still walk on it without any issues.

As far as concerning the current theme as a community effort, that may not accurately capture our options either. It was pushed forward by a few people and some threads concerning the smallest details took hundreds of comments to settle. Most people involved with that push didn't have full time jobs yet and are now pretty busy which is why it is mostly at a standstill with further progress or updates. I agree that it would be great to have a light, dark, and high contrast option but it's simply not feasible right now and I think that goal would be better attained by something like developing the ability to make use of already existing GTK themes which include high contrast options that have been tried and tested.

[RebeccaDeField]

So beyond my thoughts there and going with the more simple format that Tres posted, here is the constructive edits I can pull from this thread

• Tone down the scroll bar brightness a touch but improve it from the previous design
• Come up with a few button options to compare what makes sense on the pop up window and in the program

It's important that we try any of the ideas with the existing CSS that we can edit and not choose based on screenshots of other programs until we have done so because it will look different in LMMS and we don't want to end this thread on a "someday maybe" but something specifically achievable right now.

The scroll bar doesn't need any further debate because the middle ground is straightforward. So if we can implement some of the button ideas in the thread here and compare the options we can just pick the one that works best.

If I'm missing anything here let me know.

[musikBear]

I'll try to make this as simple as possible:

* @musikBear: pass/fail

* @RoxasKH: cosmetic approval

* @RebeccaDeField: final say

If this can happen, we can fix this issue. Anything more is out of scope. This issue has three problems to solve, they should be the focus: #7078, #6047, #4464. We have a dev willing to do this, now, so let's please band together and take advantage of that.

The picture

👍
shows a scroll-bar with fine contrast. I would be able to spot that.
Thank you.

[Rossmaxx]

From the comment by musikBear, looks like it would be better to reduce the scrollbar size with the current color scheme. Is this what you mean?

[qnebra]

For me it looks like slightly brighter scrollbar would be fine for musikBear, its not about size, but contrast between scrollbar and background

[RoxasKH]

TLDR/Summary: I agree

@RoxasKH I appreciate where you're coming from, but I'd like add a points to contrast some of the comments from myself years ago as I was a much less experienced designer when I headed the theme efforts up and my perspective has changed quite a bit.

When it comes to "accessibility" I think the idea of creating a complete alternate theme might misunderstand the major audience that needs it. This doesn't refer to people with major vision impairment, but also the evergrowing population of people who just don't see 20/20 without glasses. The idea to make the theme usable for a wide range of vision types means that this covers not just a minority but a major percentage of users all with different slight challenges. This is something that behind the scenes of existing software development, we will see major changes in waves soon due to understanding this better.

So if we can live with a slightly brighter scroll bar and still focus on using the program to do what it was made to do, and a large percentage of the users don't have to click around trying to find it then I see this as a win.

I'm reading things i've stated in my last messages too like i was someway against it. My separate theme concern was only about a fully custom theme for visual impairness like other tech does, but this doesn't mean things aren't to be addressed here.

I have a paragraph that starts with "To be noted that this doesn’t mean this pr/issues shouldn’t be covered" that you can look up, i perfectly agree that the default theme should cover most cases and be a good middle ground, while keeping in mind a certain accessibility/contrast level, and that the default theme has some really low contrast in some of the aspects underlined that need fixing (the selected dialog button is a very good example of it, and i guess scrollbars too).

We can tone down the brightness ever-slightly to reach a compromise and then move forward with it. If we receive a lot of complaints or requests due to the brightness being too much we can tone it down further but I think debating between a few people won't be a good indicator of whether it will even be noticed or cause problems for the overall audience.

Agree. I'm fine with the scrollbar being on a higher level that the quick mock i did, it's like the 3rd time i'm saying this. All i need is for it to be more distinguishable, but also not to get that much eye attention.

These bright yellow sidewalk entry markings are not reserved for a separated sidewalk because the rest of us can still walk on it without any issues.

I don't think i fully agree with this example as a comparison: you don't have to constantly be looking at a path while you're walking on it, and looking at it doesn't interfere with its "usage", unlike with using a software. I get the general message tho and i agree with it, obviously. More and more software is focusing on accessibility for very good reasons (although i still liked the old Discord blurple and pale colors more sigh).

As far as concerning the current theme as a community effort, that may not accurately capture our options either. It was pushed forward by a few people and some threads concerning the smallest details took hundreds of comments to settle. Most people involved with that push didn't have full time jobs yet and are now pretty busy which is why it is mostly at a standstill with further progress or updates. I agree that it would be great to have a light, dark, and high contrast option but it's simply not feasible right now and I think that goal would be better attained by something like developing the ability to make use of already existing GTK themes which include high contrast options that have been tried and tested.

I'm all in for shortcuts to get accessibility more easily, if possible. All i've been saying is that i don't think we need a full super high levels contrast theme as the default.
About the current theme, it looks like i was wrong and didn't start from a single community user. I was probably fooled by bad memory and the existence of a backport on LSP (https://lmms.io/lsp/?action=show&file=11896).

Come up with a few button options to compare what makes sense on the pop up window and in the program

I've given a couple of options to brainstorm on and hopefully we'll get to something that fit and helps visibility

---

From the comment by musikBear, looks like it would be better to reduce the scrollbar size with the current color scheme. Is this what you mean?

I think they were just answering tresf question on what would be a good/visible contrast amount for them based on the garageband screenshot.

[tresf]

From the comment by musikBear, looks like it would be better to reduce the scrollbar size with the current color scheme. Is this what you mean?

I think they were just answering tresf question on what would be a good/visible contrast amount for them based on the garageband screenshot.

Agreed. If all in agreement, can we please get some mockups now so that @Rossmaxx can code this up?

[RebeccaDeField]

@musikBear

Thanks for the feedback!

--

@Rossmaxx

I used a contrast ratio checker and the contrast from the background to the scroll bar in the screenshot MusikBear approved has a ratio of 2.5

I pulled the colors from your own screenshot and adjusted it to a 2.6 ratio, here is the hex value I got from that: #5d6b77

You can go lighter on hover though it's a temporary state so I don't think the brightness of that matters much so maybe a middle ground can be: #b8c4d1

This ironically turned out to be quite literally half of the value we originally proposed so I think that should be a pretty final conclusion as a middle ground.

--

@RoxasKH

Not every point in my comment was intended as an opposition to your thoughts, though sorry if it seemed that way because I did @ mention you in the intro and text can be like that. A lot of my remarks were regarding my change of stance from the past and some general rules of thumb I meant to propose for us to follow going forward.

No worries about the LSP confusion! Glad we're on the same page.

You mentioned that you already added some ideas for the buttons. Can you compile the ideas you think work best into a reply? And are they mockups only or real-life screenshots from inputting the values that we need to try in-program before we approve one of the options?

[Rossmaxx]

@RebeccaDeField thanks for the hex values. I will get back with screenshots after I replace the hex values.

[Rossmaxx]

Much better. Thanks for the color recommendation. @musikBear is the scrollbar ok now?

[Rossmaxx]

Also, I'm thinking of removing the button active effect as fixing that one might require some more effort (as in creating an entirely new widget class and stuff, which is beyond me. I intend this as a simple change).

[Rossmaxx]

I will merge this in 2 days if no one objects. @musikBear if it's fine, I'll merge earlier.

[RebeccaDeField]

@Rossmaxx You have my go-ahead from the design dept, so if this passes to @musikBear we are set to merge. If there is no response feel free to merge in two days.

[musikBear]

Much better. Thanks for the color recommendation. @musikBear is the scrollbar ok now?

The contrast look fine.
How does it look maximized?

[Rossmaxx]

@musikBear here you go

[RoxasKH]

@musikBear

Thanks for the feedback!

--

@Rossmaxx

I used a contrast ratio checker and the contrast from the background to the scroll bar in the screenshot MusikBear approved has a ratio of 2.5

I pulled the colors from your own screenshot and adjusted it to a 2.6 ratio, here is the hex value I got from that: #5d6b77

You can go lighter on hover though it's a temporary state so I don't think the brightness of that matters much so maybe a middle ground can be: #b8c4d1

This ironically turned out to be quite literally half of the value we originally proposed so I think that should be a pretty final conclusion as a middle ground.

--

@RoxasKH

Not every point in my comment was intended as an opposition to your thoughts, though sorry if it seemed that way because I did @ mention you in the intro and text can be like that. A lot of my remarks were regarding my change of stance from the past and some general rules of thumb I meant to propose for us to follow going forward.

No worries about the LSP confusion! Glad we're on the same page.

You mentioned that you already added some ideas for the buttons. Can you compile the ideas you think work best into a reply? And are they mockups only or real-life screenshots from inputting the values that we need to try in-program before we approve one of the options?

(Sorry for replying late)

My ideas for the buttons are here: #7202 (comment) (i also mentioned in that same message the loop button issue where some of the things were in common)
They're just mockups, although one of the 2 consists of just color changes, mostly because i don't have much time nor i know my way that much on the CSS post refactor.

Now those are just ideas, i myself have no idea which might suit better or if there are even better alternatives, so well, i'm looking for opinions too.

The new scrollbar changes are mostly fine with me, but i'm wondering how are we feeling about the pressed state using pure white.
Most of other apps i've seen and most of the pressed states usually gets to a darker shade (even if slight) of the color (even in the current LMMS theme, pressed buttons behave this way) to give the feeling to user instead.

It's also true that it'd be weird to pass from shade -> lighter shade on hover -> darker shade (so near the first one or some inbetween) again.
I haven't seen the hover state on scrollbar being there so much, but also some apps has moved to some kind of collapsing scrollbars, which expand on hover.

FL Studio has 2 types of scrollbars, one with an hover state, but no pressed state, and one with no hover but with pressed.
That said i'm not sure how much accessibility is among their concerns considering they have this scrollbar

I know it looks like i might be keeping this away from merge, but early merges aren't always the greatest thing, so i wanna gets stuff ensured before merge.

Buttons can also be addressed here if we find something that works and for the time being we avoid introducing the weird behaviour that the focused state introduced. It might need some digging cause it looks like the focused state was added from scratch and then removed. So this makes me think the current theme has no focused state, but i definitely some slight darker shade on selected buttons inside dialogs like the save one. It could also just be some default Qt stuff.
That said they can also be moved to another PR without issues.

I do wanna clarify that when i'm saying buttons, i'm talking about the dialog buttons. #4464 would need a lot of work to make something like that fit in the current theme, considering the buttons have gradients, and the guy in the issue was definitely referring to something like this, although they didn't post screenshots.

[Rossmaxx]

@RoxasKH can you add your points regarding the button active state in #6047 if you haven't already.

[musikBear]

@musikBear here you go

Look fine! Good job Ross 👍