Skip to content
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

Improve accessibility, particularly relating to color #353

Open
windymilla opened this issue Jul 30, 2024 · 5 comments
Open

Improve accessibility, particularly relating to color #353

windymilla opened this issue Jul 30, 2024 · 5 comments
Labels
future feature New feature or request, but not core

Comments

@windymilla
Copy link
Collaborator

windymilla commented Jul 30, 2024

At the moment, things like the key bit of text in a checker dialog error message are shown highlighted in the same foreground and background colors as the OS scheme "selected text" (e.g. Windows default is white text on blue background).

Some may not find colors distinguish the text sufficiently.

Therefore:

  1. Consider how many of the colors used need to be user configurable
  2. Consider the optional use of underline, borders, bold, etc., in place of, or in addition to the colors.
@srjfoo
Copy link
Member

srjfoo commented Aug 3, 2024

One comment I've seen over and over again about accessibility is that we shouldn't be depending just on color.

@windymilla
Copy link
Collaborator Author

Additional note re colors: At the moment, something like highlighting ("spotlighting" in the code to distinguish from other highlights) is set to have an orange background, and either black or white text depending on if the theme is light or dark. However, in the "default" theme case, the current code assumes it's "light" and sets the text color to be black on orange. If, as is possible on a Mac, the default theme follows the system theme, the default may actually be dark with white text. The highlighted text is then black on orange when it should really be white on orange.

One solution would be to leave the Text foreground color unchanged, so it matches the rest of the text, but with an orange background. However, suppose your Mac theme had orange text - it would then be unreadable against an orange background. So, it appears as though it is necessary to set the fg as well as the bg color.
Another solution, given that we have chosen bg colors where either white or black text would work, would be to inspect the main text fg color (which will usually be black/close to black/white/close to white) and force the fg color for highlighting to be either black or white depending on which is closer the main text fg color. Then on a light default theme (with dark text) the highlight text would be black, and on a dark default theme, the highlight text would be white. This would be perfect for most themes, and would still be acceptable for unusual themes, e.g. with orange text.

All of the above may be irrelevant depending on if/how/how many colors we make user-configurable.

@windymilla windymilla mentioned this issue Aug 4, 2024
@srjfoo
Copy link
Member

srjfoo commented Aug 4, 2024

A couple of comments:

My impression (and I don't remember where I read/heard this) is that if you're setting a background color, you should always set the text color, also. Mind you, this is mainly as applied to HTML/CSS, but I see a parallel here.

I think, as long as you set both bg and fg colors to be readable, it doesn't really matter what theme the user has set, it's still readable. I certainly don't object to having black text on a lighter highlight/spotlight if the spotlight needs to be light.

@windymilla windymilla added the core feature Required for basic PPing label Aug 6, 2024
@srjfoo
Copy link
Member

srjfoo commented Sep 26, 2024

I know we're not quite ready for beta releases yet, but I would not delay the first beta release for this, even if it is tagged as a core feature. I think that ultimately, we need input from the community, especially those who have accessibility needs.

@windymilla windymilla added future feature New feature or request, but not core and removed core feature Required for basic PPing labels Sep 27, 2024
@tangledhelix
Copy link
Collaborator

There are some notes in #521 and #523 for later review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future feature New feature or request, but not core
Projects
None yet
Development

No branches or pull requests

3 participants