[FEAT] Add contrast metrics for improved accessibility

[friscorose]

Is there an existing issue for this?

• [ x] I have searched the open issues

Accessibility guidance for designing color themes suitable for those with vision impairment

Determine acceptable colors and contrasts on UI elements

There are many types of vision impairment and creating themes suitable for those users is a good thing™.

One of the most obvious metrics is contrast metrics. Well defined standards https://www.w3.org/TR/WCAG22/ already exist and many tools to verify compliance also exist (lmgtfy: https://www.google.com/search?client=firefox-b-1-e&channel=entpr&q=contrast+standards+for+vision+impaired ). Having a measurement for contrast would be very nice in this theme designer.

Other enhancements could also be added such as test for themes that work with specific color blindness etc.

Alternatives considered

Possible implementation

A simple metric indicating contrast in a focused UI element would go a long way toward ensuring broad accessibility. More advanced tools that suggest possible color pairings would also be a nice feature.

Additional context

As a parent of a red/green colorblind child I always appreciate it when I see good UX that supports accessibility theming. Thank you for taking the time to consider this request.

[TomJGooding]

I really like this idea, but I'm worried about the complexity involved in its actual implementation.

Most widgets aren't simply $foreground on $background or $foreground on $surface. There's a whole host of other variables, for example the blurred/focused/hovered states, as well as the 'cursor' color for widgets like the DataTable or OptionList.

[friscorose]

Just for starters: A simple two color selector showing a contrast metric should be easy(ish). A user would need to do the work of considering what colors would be involved, but at least the metric would be right there rather than going out to some external resource. Adding more could be a more organic progression of suggestions.

Happy to dive into this at length if desired. Thanks for taking the time!

[TomJGooding]

The problem is that it's not as simple as checking the contrast between the theme's 'core' colors.

For example, consider this excerpt from the default CSS for the OptionList:

        & > .option-list--option-highlighted {
            color: $foreground;
            background: $block-cursor-blurred-background;
        }

The background color here is derived from primary.with_alpha(0.3). Any meaningful contrast metrics would need to account for all such variables based on the theme.

[friscorose]

OK, tricky...yes, but... just thinking out loud now, no idea if this could actually work. What if you call

app.screen._compositor.render_update(
            full=True, screen_stack=self.app._background_screens, simplify=simplify
        )

and read out the segment style color attribute(s) for the cell coordinates under the mouse pointer - a sort of color picker /magnifying glass action triggered by a key binding event? Then you could feed the 1st and 2nd event colors into a contrast metric method. Maybe? (I should try this out myself.)

[TomJGooding]

I think any 'inspector' like tool is way out of scope for this project, I'm afraid.

I still like the idea of somehow checking the contrasts, but I'm just not sure yet the best way to implement it.

[TomJGooding]

Some 'notes to self' after another read through the Textual theme documentation:

• The default background color of (most) widgets in Textual is $surface.
• The docs suggest that text "should be legible on $background, $surface, and $panel backgrounds". Rather than report the contrast for every possible theme color combination, perhaps these backgrounds should be the main focus.
• This is complicated by the fact that "[f]or every color, Textual generates 3 dark shades and 3 light shades". There's also the '-muted' and '-disabled' variations to consider.
• Widgets with a 'block cursor' (OptionList, DataTable, etc.) by default use the $block-cursor-background/foreground colors (which also have variations such as blurred).
• There's also variables specific to certain widgets, such as $input-selection-background and $footer-background.

[friscorose]

If you want to create an inspector I hacked together a POC for a full screen cell color inspector gadget. Very bare bones, but it has the basics for how a nicer, more robust implementation could be put together.

[TomJGooding]

Sorry but I don't want to create an inspector.

Since you're clearly passionate about this and already have a POC, maybe create your own package?

Fair warning though: even if your inspector tool is designed only for colors, I suspect you'll see users expecting a full devtools.

[friscorose]

No worries! I just want to see Textual have the best in class features so that it gets broader acceptance. I dreamed of TUI framework like Textual many many years ago but the whole project was/is beyond my abilities to create. Now I just toy around with what Textual can do hoping to help move it toward popularity/standardization.

Thank you for considering this feature for your theme editor and I look forward to what you turn it in to. Please feel free to close this if it helps keep things cleaner for you.

[TomJGooding]

I still like the idea of a contrast checker, but just not everything involved with an 'inspector' like tool and the inevitable mission creep.

Now I just toy around with what Textual can do

Me too. This exists only because I wanted to see if it was possible to create a color picker.