Handmade: A Community for Self-Rolled Performant Software (2016)

It could be written for one person and mass-distributed with the understanding that you are using software written for Bob's needs.

>I'll just add here that it's precisely the economics of large-scale software distribution that allow concerns such as internationalization and accessibility to be addressed, while a solo Handmade project will probably not have these important things.

You have mixed up cause and effect here. Internationalization is a concern caused by mass distribution, not an existing concern not being addressed. The same goes for accessibility. Handmade software will meet the accessibility needs of the one person it is written for. Have different accessibility needs? That is a different piece.

This is a debate/discussion I've been having for 20+ years now (as the original author of Ardour).

The GUI of a typical DAW (or even a moderately sophisticated plugin) serves as memory aide for sighted users. 48 tracks? Which ones did I mute? A sighted user doesn't have to remember - they can just look.

Sight-impaired/blind users of older hardware mixing consoles use the tactile experience of those devices to partially fulfill the same role, which is why modern full digital consoles with tap-only-LED-lit buttons are so much harder for them to use: they have to either remember or investigate which features are enabled and which are not.

In addition, most DAW and many plugin GUIs present information in ways that are more or less inconceivable for screen reader presentation. Waveforms are the obvious example, although here perhaps sight-impaired users have what some would consider an advantage, in that they are forced to work entirely by ear, rather than use on-screen representations that have only a debatable relationship with the sound.

But routing presents another area where it can be very difficult to present the current state in a way that could ever be rendered meaningful by a screen reader.

Please don't think that I don't view accessibility or i18n as of critical importance - I absolutely do. But I also think that when application niches (like audio production) evolve their own highly-developed visual language to supplement and assist (sighted) users, that the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation.

This is one area in which Linux is far ahead of Windows and macOS: there are numerous command line applications available for audio production which would strike utter fear into the hearts of most sighted users, but that turn out to be incredibly great for sight-impaired users. Ecasound, I'm looking at you (among others).

That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects.

There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today.

Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.

> the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation.

This cuts to the heart of a long-standing debate among accessibility advocates and blind techies. It's true that tools tailored specifically for blind people can be more productive and easier to use. But they can also isolate the blind community from the sighted mainstream. For example, would a DAW developed specifically for blind people enable them to collaborate with sighted peers, or to use one-of-a-kind plugins that are developed for mainstream DAWs with a visual interface? This is why, while retrofitting accessibility onto a GUI is often suboptimal, it's necessary.