My opinion on #Calckey, and the other *key forks:
The accessibility isn’t “needing improvement”. The Akkoma-FE needs improvement. Calckey’s accessibility is “practically non-existent”.
This is one of the most advanced Fediverse front-ends with several bespoke complex widgets, which makes accessibility a challenge; it needs to be a priority from the start. Yet it seems to be designed in a way to override all the native browser behaviors to make an interface accessible. It’s dug itself into a moat.
From a minute with the front-end, I see this:
Buttons don’t have readable accessible names.
Much of the interface isn’t keyboard-reachable.
Heavy animations don’t respect reduced-motion settings.
Loading indicators lingering on the accessibility tree.
All the fancy floating windows are contained in section roles that lack accessible names. The title bars are broken into multiple static text elements, one of which is a Unicode symbol.This was all within a minute of using Calckey. A more thorough look would probably reveal far more.
I’m not optimistic about bolting accessibility onto an already-complex front-end, but I don’t find the situation hopeless! Effort is probably better spent supporting MastoAPI so people can use accessible clients, and on getting non-Calckey servers to support federated back-filling of missing replies so we don’t have to view posts on a remote Calckey instance’s front-end. It may also be possible to create a separate, more-accessible “read-only” static front-end. Akkoma’s static-FE (not enabled on this instance but visible elsewhere) is one good example of this approach.
Everything I wrote should also apply to the other *key forks (Misskey, Foundkey, etc).
I’d be happy to be proven wrong about any of this.
Edit: Calckey appears to have added support for reduced-motion, and will soon get better keyboard support.