> APCA models how human eyes actually perceive contrast, factoring in font weight, spatial frequency, and ambient light — a genuine improvement over the WCAG 2.x formula. […] The research behind it is peer-reviewed and substantive
That's what the author claims, but I have not seen any evidence that it is actually true. In a ticket where they were asked to provide peer review, they instead linked to a bunch of blog posts that in my opinion do not qualify as peer review: https://github.com/w3c/wcag3/issues/29
Also, it is not as if the WCAG 2 formula would not model how humans actually perceive contrast.
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 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.
Looks like a helpful honeypot! Any tool that will public announce support for this spec is a tool I know to avoid because it collects telemetry without explicit opt-in in the first place.
I was working on something similar a while back (https://github.com/xi/spreadsheet) but ended up not using it. I just didn't end up being the first tool that came to mind when I was reaching for a spreadsheet. Not sure why.
I will definitely try out your tool and check if it works better to me.
Two random thoughts:
- In excel I often use the dragging feature, i.e. use a formula like $A2 + B$1 and then drag it in both directions. Does your tool have something similar?
- Another nice feature are visualizations. In my tool I added a bar() function that renders a value between 0 and 1 as a bar in the cell. Not sure how flexible that is, but I did have some fun with it.
I am working on https://github.com/xi/xiio, a minimal async runtime for python. It is mostly feature complete with a fraction of the code of asyncio or trio. It is great fun to get into low level stuff and hopefully it helps me to better understand the finer details of async programming.
I am still confused what exactly this tool is doing. I clicked on "examples" in the hope of finding an example of a generated policy. But it only gives examples of the configuration, not the output.
I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction.
Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
I also find building apps for the web is much easier than any of the native frameworks. You can start by writing plain text in a file and then progressively add HTML, CSS, and JS. The app described in the article is trivial to implement in the web.
A lot of that comes down to the huge community and the shear amount of documentation that exists. OTOH, nowadays you will quickly be distracted by frameworks and build systems.
IMHO the biggest hurdle is hosting, but github pages makes even that somewhat easy.
The README talks a lot about crypto. But the interesting bit is how you can access the passwords. Is there an API? If yes, how does it protect your passwords from malicious software? If not -- are you sure? (Have you checked for example accessibility APIs by the platform?)
It is a Maneki-neko (beckoning cat / Winkekatze). The video team started putting them on podiums so they could see when a stream was frozen. So it became kind of a mascot.
This is probably a Linux issue. Mac OS and Windows implement the FIDO2 Platform API, which allows them to act as authenticators themselves. Linux does not. See https://github.com/linux-credentials.
I also think these are very similar. The main difference in my view is that the state parameter is checked by the client, while PKCE is checked by the server.
I run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.
> For coders, visual aesthetics don’t matter. For lawyers, they are a technical requirement. While this difference may seem arbitrary on the surface, it is downstream of a critical technical difference between the two fields. Machines interpret the work of coders. Human institutions interpret the work of lawyers.
I believe this is not only infuriating, I am pretty sure it is actually illegal. If lawyers would think that visuals are more important than semantics, they would explicitly discriminate blind people.
That's what the author claims, but I have not seen any evidence that it is actually true. In a ticket where they were asked to provide peer review, they instead linked to a bunch of blog posts that in my opinion do not qualify as peer review: https://github.com/w3c/wcag3/issues/29
Also, it is not as if the WCAG 2 formula would not model how humans actually perceive contrast.