ximm

Absolutely, this is accessibility 101.

The one counter argument to this that I would accept is that users don't know about font settings. But the proper solution if for browsers to make it easier those settings rather than every single website having to add font controls.

Honestly, I really never had specificity issues (apart from some third party CSS adding styling with high specificity)

How is that? I also like CSS, but when I looked at the @layers spec I didn't see any immediate use case.

But it is really up to the author to decide what "canonical" is. I serve my blog in markdown by default and only switch to html when it is explicitly requested.

Not sure if this is the case here, but it might be that you pay in data if you use the app.

Flatpak itself might not survive, but the underlying protocols (portals, security contexts in wayland, pipewire, and d-bus, systemd-appd, …) are relevant for sandboxing on linux as a whole. While I do not personally with every design decision, I still think this is useful and valuable work.

There is also the option of structural funding (Strukturförderung in german) where important organizations receive multi-year contracts instead of short term project funding.

Corrected version:

A wealth tax of 1% is equivalent to an income tax of 20% on capital gains.

Are there any recommendations for testing accessibility for TUI applications? The article mentions speakup, but as far as I understand, you need a hardware synthesizer to use that. Is it also possible to use orca?

I am not sure it is helpful to shoehorn terminals into being a second web. The terminal's strength is its simplicity.

For example, I really dislike mouse support in TUIs. 100% of the times I used the mouse on a TUI, I wanted to copy a piece of text. If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying.

Of course a11y is important. But it barely works on the web and we won't get perfect semantics on the terminal without a lot of work. I say the better option is to strip down the experience to the parts that work well.

My experience as a developer (with a preference for simplicity):

- CLI by default

- if I need a GUI, but no access to the local system: web

- if I need a (restricted) GUI with access to the local system: TUI

- else: either start a local web server, or, if nothing else works, go for a GUI toolkit

My experience is that often when I think "I wish my email / browser / calendar / … did X" it turns out be a limitation of the underlying protocol. So even if you build all software yourself, you still have to make compromises when you interact with the outside world.

Is the text on this page really #bbbdc3 on #ffffff? How is anyone supposed to be able to read that?