@sonny Dunno how, but I wish every electron app (VSCode, Slack, etc) was packaged on Flathub with the right options so that fractional scaling works on Wayland. I had to disable fractional scaling because of that, I don't want to hack every app launch options.
Not sure if this is an accessibility issue, but the flatpak CLI app should really say if the app is packaged by the developer or not, and give a warning if the packager is not the developer.
it'd be nice if flatpak supported reproducable builds and gave info on that as well.
@sonny i would say that flathub really misses a easy way to get to know and install applications' extension.
Often extensions are good for adding accessibility across applications, but without a clear interface it's quite hard on the UX
@sonny Colorblindness in general should get more consideration overall. And I'm not talking about slapping a distortion filter over the entire system.
I've used them on tons of platforms, & ALL of them are virtually useless regardless of which "-tanopia" filter or strength I apply. The only way I perceive the diff between similar colors distorts my perception of the color to the point where I lose any intuition of what the new altered color is supposed to be.
@sonny These filters also destroy things like photos, where I would prefer resemblance to reality over the crutch of making pinks extra pink.
The most effective tool for me on any system has been manually color picking the hex value of whatever I am unsure about. Facilitating that UX would be an easy-ish low hanging fruit.
Selectively applying those filters on-demand with a UX like GNOME screenshots would be far superior to constant distortion.
I wouldn't have to second guess what the original color looks like, and I could also quickly apply the filter when I want to blow out the hue differences.
@sonny What would most help me is to have a system-wide option that prevents apps & shell from using hue to express semantic meaning.
Monochromatic UI that varies brightness or saturation to express meaning would be a significant improvement.
Even more effective would be to use other styling effects to express that meaning instead (like animation, border thickness/dashes, background shading patterns, or element margin/padding)
@redstone@sonny I proposed something like that for x-d-p but the problem is that it needs implementations in toolkits/apps first.
The accent color setting already is a good step in the right direction but when toolkits/apps start deriving their own color from that, or if they generate random colors for e.g. tags, then it would indeed be very useful to have information about color vision deficiencies...
Add comment