@skye *nodds in agreement*

Also #accessibility will benefit everyone and harm noone, so it's a clear winner!

It’s not about harm, but *cost*. Yes, building accessible apps is usually worth the investment, but it’s never free. Now consider that *free* software is usually maintained by a lone developer who is already stretched thin just making the thing work. If you like an open source app, your best way to get accessible features is by donating your time or money to make it happen. It’s true for all apps, but doubly so for features that serve a minority of users. @kkarhan @skye

@benpate @kkarhan @skye Making it in a local client-server pattern can be very useful regarding this, as it enables users to easily swap-in alternative frontends.

Many applications could easily be wrapped with #Elisp & #EmacSpeak by users for practically free first-class audio desktop support.

#Emacs

Great example. Open APIs always win. I’ll check out EMACSpeak to see how it might fit with my work. In the ActivityPub world, I’m still bullish on the ā€œclient to serverā€ (C2S) APIā€ that literally nobody has implemented. With any luck, we may get some first tier clients that work with more than just Mastodon. But in the meantime, accessibility a costly uphill battle for sure. @lispi314 @kkarhan @skye

@benpate @kkarhan @skye Oh yeah, C2S has been a persistent pain-point for me regarding ActivityPub.

Basically everything implements the Mastodon API instead, but they all implement it in subtly incompatible ways.

@lispi314 @benpate @skye

OFC I do acknowledge that #Accessibility isn't usually the first priority, but getting it up and running is more important...

Still, I think that seperating backend and frontend can make that process easier espechally if an app is also intended to get #i18n / #Internationalization and #l18n / #Localization.

OFC I don't expect every little #CLI tool to come with a multi-languaged TTS & Voice Command interface...

https://mastodon.social/@benpate/110759330031212989