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.