Creating that API in the first place would require a whole lot of work on VCV’s end to make possible. My original hypothetical was predicated on the notion that VCV would be able to put in that effort and provide a good API which would then not be particularly difficult for developers to implement.
If everything was designed well on the Rack end, I imagine that for plugin developers it wouldn’t involve much more than specifying descriptive tags for each input, output, parameter, and visual indicator. Tedious, but nothing that would require anyone besides Vortico to purchase assistive technology for testing (or hire someone to test for him). Some of this is already on the way with Rack 2’s new API for tooltips.
Of course, I don’t expect this to actually come to Rack any time soon, and I don’t fault VCV for it, because Vortico has a whole hell of a lot on his plate already and the operation isn’t big enough to hire people to do it for him.
Most realistically, a screen-reader-enabler would probably be feasible as some kind of Stoermelder-esque module which developers could opt-in to supporting like the portable sequence standard or Lights Off. I might look into it.
In any case my original intent wasn’t particularly to discuss screen readers, but mostly to highlight the question of whether it is a commercial issue for an optional feature to be made available which some developers might not implement. The idea of the accessibility symbol was meant to drive this home, as a means of determining how much VCV should or should not need to protect developers from being left in some sort of out-group and then to weigh that against the usability concerns of a minority. This seems to be the crux of the issue as far as Vortico is concerned.