Conversation

Notices

1. Embed this notice
   Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:38:35 JST Matt Campbell

   Interesting post about the "Handmade" programming community: https://www.rfleury.com/p/the-marketplace-of-ideals

   Unfortunately, the author isn't on the fediverse, or I'd mention him.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:38:32 JST Matt Campbell

     in reply to

     I've tried to put forward a compromise with my AccessKit project, allowing a variety of GUI toolkits, based on different architectures and implementation tradeoffs, to share accessibility infrastructure, in the hope that many more non-bloated, or at least less-bloated, GUIs will be accessible.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:38:32 JST Matt Campbell

     in reply to

     It has taken me a while to come to terms with the fact that my solution, being a library and an abstraction layer, and one written in a programming language (Rust) that tends to be polarizing, will not be acceptable to everyone. I've been aware of the Handmade community since shortly before I started AccessKit, and I now believe I've fretted too much about trying to make my library acceptable even to that group, to the point of wondering whether I should have used Rust at all.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:38:33 JST Matt Campbell

     in reply to

     On the other hand, the "handmade" GUIs I've seen are, without exception, inaccessible with screen readers. Say what you will about software built on towers of abstractions and dependencies; these things do make it more likely that applications will be accessible.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:38:34 JST Matt Campbell

     in reply to

     I'm ambivalent about the Handmade ideal. On the one hand, their frustration with the state of modern software, expressed somewhat in the previously linked article and at length in the original Handmade Manifesto (https://web.archive.org/web/20160408150158/https://handmade.network/manifesto), resonates with me.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:27 JST Matt Campbell

     in reply to

     Lately, though, it has occurred to me that the true "Handmade" response to GUI accessibility might be that the current approach, as implemented by the platform accessibility APIs and current assistive technologies, is misguided, and that something like AccessKit is merely trying to mask the current complexity rather than eliminate it. I'm reminded of another post by Ryan Fleury: https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator particularly the section "An Alternative Approach: Change The Problem’s Nature"

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:37 JST Matt Campbell

     in reply to

     I've often thought that the current mainstream approach to accessibility, i.e. accessibility APIs and external assistive technologies, is an unequal approach to UI. GUI toolkits and applications have full control and responsibility for the visual UI, but for other modalities, the toolkit or application exposes a generic representation of the UI and leaves the details to an external assistive technology.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:38 JST Matt Campbell

     in reply to

     I've wondered lately if it would be good to double down on the self-voicing (or more generically, self-outputting?) approach. The current Windows "screen reader APIs" (that's what we call them), including the one I developed myself 10+ years ago, are too simplistic; they don't allow the application to be called back when a speech utterance is complete or when a button is pressed on a Braille display, and they don't allow applications to take over screen reader keyboard commands.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:39 JST Matt Campbell

     in reply to

     Someone looking at GUI accessibility without knowledge of the current solutions would probably conclude that the obvious way to make a GUI accessible is for the GUI toolkit itself to support alternative input and output methods. For example, the GUI toolkit could directly render the text to be spoken or shown on a Braille display. And in fact, for the most part, the games that have been made accessible to blind people have implemented accessibility this way.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:39 JST Matt Campbell

     in reply to

     On Windows, what we often call the self-voicing approach is made more practical by the fact that the major third-party screen readers offer APIs for sending text strings to the screen reader to be spoken and/or shown on a Braille display, so applications that take this approach don't have to use their own text-to-speech engine. None of the platform-provided screen readers offer something like this though, even on Windows.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Monday, 02-Oct-2023 02:39:40 JST Matt Campbell

     in reply to

     Disclaimer: I'm thinking out loud here, not announcing that I have the definitive answer.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 02-Oct-2023 02:46:57 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @matt I would usually agree on this different client approach, as you end up with pretty different representations of some data, the issue I see though is that accessibility needs are typically a spectrum, so interfaces should try to be flexible enough.
     Plus different interfaces often means different features available due to catering to different need-of-the-moment where people could mix rather than people, like I've yet to see a non-GUI VoIP/audio-chat application (not blind, just that my main clients tend to be in terminals).
   • Embed this notice
     chris (chris@s.the-brannons.com)'s status on Monday, 02-Oct-2023 04:47:19 JST chris

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan @matt
     Apologies for hijacking the thread, but I saw the mention of non-GUI
     audio chat.
     
     There are a few non-GUI VOIP and audio chat solutions.
     There's the Mumble client barnard, https://github.com/bmmcginty/barnard.
     This has bit-rotted to a certain degree. It has become wildly unstable,
     either due to changes to Go or to libraries that it is using. And I know
     of at least one memory leak. I'm too sick nowadays and don't know Go well
     enough, or I'd try and fix it. Funnily enough, it is far more stable on
     FreeBSD than on Linux. And yet, there are a few blind people (me included)
     who use it all the time.
     
     SIP from the terminal has been around in some form for a while: pjsua,
     baresip, and the linphone command-line client linphonec.
     I use baresip in daemon mode, where it accepts commands over TCP. Commands
     and responses are sent as netstrings. So this is pretty easy to work with.
     I wrote a little command line program, bscmd, for sending commands to it.
     So I can make and receive calls directly from my shell.
     `bscmd dial sip:+18004444444` will dial a landline phone number through my
     VOIP provider, and `bscmd accept` will answer an incoming call.
     `bscmd hangup` to end a call, `bscmd mute` to mute. I've used this plus
     a land-line dial-in number to participate in Zoom calls (without video of course).
     All from the comfort of a Unix shell.
     Haelwenn /элвэн/ :triskell: likes this.