My two cents: Vortico’s decision not to implement an official dark mode was predicated on two points:
Dark mode has near-zero actual benefit
It could lead to a blemish on commercial plugins which do not put in the significant work to support dark mode
It is understandable for VCV not to chance making commercial partners look bad, and risk losing purchases.
It’s been mentioned a few times in this thread that for some, and particularly for the visually impaired, having official dark mode support is a significant usability concern. I think this contradicts Vortico’s first point, and therefore changes the calculation regarding the second point. From this perspective, maybe he will reconsider his rejection of the proposal.
I agree that creating an official dark mode would create two classes of haves and have-nots in the Library. It’s possible this could dis-incentivize some commercial module purchases, though I’m not sure by how much really. As for those who need dark mode, they were likely never prospective customers in the first place.
When it comes to accessibility, I think it’s worth providing developers with clear avenues, and perhaps more importantly, incentives to cater toward minority users. At the risk of going out on a limb with my reasoning here, I’ll say that I personally think it would be a good idea to build JAWS/NVDA support into the Rack API in order to make it easy for module developers to cater to blind users effectively, and modules which pass a test for soundness of their implementation of this hypothetical API ought to get a badge of honor displayed next to them in the Rack Library.
In the long run, it seems like it wouldn’t be particularly difficult for VCV to get good optics by branding and marketing this sort of effort to reward developers for accessible modules, and as a purely business-oriented calculation maybe it would end up as a net positive for the bottom line?
I’d be out of the VCV dev scene if there were an expectation I should test with assistive devices for blind users or be considered low quality. This hobby isn’t a day job lol. And I say that as a developer who went out of my way to make my collection accessible to users with Tritanopia without anyone asking.
many commercial modules already offer multiple (as in more than two) different choices for panels. any time you offer an odd number of choices, you break the “dark mode” paradigm.
this decision was made over 9 months ago, I question why it’s being rehashed again suddenly.
By expectation, do you mean you wouldn’t want other developers’ plugins to get a badge which says “VCV Visually Impaired Accessibility Collection ”?
As a hobbyist developer, I don’t understand how VCV leaning into highlighting more accessible modules would place any kind of financial burden on hobbyist developers. In this case it seems like the only people who would really care that you don’t have a would be those who you weren’t ever planning on catering to anyways.
I don’t think that breaks the dark mode paradigm. Each of your panels would need to be labeled dark, light, or both. Users would set their default light panel and default dark panel separately. When Rack would signal to switch from light to dark mode, each module would switch from the default light panel to the default dark one.
The decision was made 9 months ago, but as you can see on GitHub there was no further discussion until 2 days ago. Some of this thread ought to be taking place over there instead. It wasn’t until now that we’ve had someone publicly announce they are prepared to provide people with a way around the lack of an official option, so I think it makes sense to cover all the angles here.
The whole uncomfortable discussion about licenses on the graphics, and how much of the design is covered by CC vs how much is covered by GPL, and perhaps how much of it may be in the realm of patent or in fact represent totally un-protectable elements of the design and therefore actually not covered by either license at all… It can all be avoided if it turns out that the original decision was made on a false premise and may be reversed.
If there were a little seal of quality reward, its absence would convey low quality.
If I knew I had no way to qualify for the seal of quality simply by doing what I’ve done so far, I’d just go find a more rewarding hobby without a perverse incentive to gamify my behavior.
Perhaps it’s a significant error to think of it as a pretty & shiny badge. What if it looked like this? No shiny, just internationally understandable symbology.
I think that a lack of a seal of accessibility wouldn’t signify low quality. It would signify potentially low accessibility, which is the idea.
Considering there is no XP involved, no levels being gained, no artificially contrived constructs of reward at all, I don’t think this represents gamification in the slightest. Making it easier for disabled people to find products designed with them in mind is not an artificial game design construct. Compliance doesn’t even signify that much of a reward for the developer.
More than anything it would simply stand to benefit the disabled users, and connect them to developers who decided to cater to them for personal reasons (disabled family, friends, self) or financial reasons (gunning hard for the assistive technology market) or other reasons (boredom?).
I don’t think it’s disingenuous to think of Andrew Belt as a human being who may have been working with incomplete information at the time he made the decision. People make mistakes.
Of course I respect his status as maintainer and rights holder, as well as the owner of this discussion board. If he chose to lock this thread, I would understand.
I myself followed the original discussion last year, and for me reading this thread was eye opening. The accessibility angle was something that I personally had never considered, and to my knowledge was not a part of the original discussion last year. So I thought it was worth highlighting that point, taking it to its logical conclusion, and considering it. I thought maybe I wasn’t the only one who would find this an eye opening angle on an old topic. (In the context of this discussion, I really wish I didn’t use visual metaphors so often…)
Thank you for sharing your thoughts, sincerely. I personally value your contributions to the library and this community.
Framing it as an objective fact about whether it’s supported rather than as a little trophy bundling multiple criteria absolutely makes all the difference.
I personally know how to make websites that are reasonably accessible to blind users, and how to test them with automated tools, without having to buy and learn assistive tech. I do it because it’s almost second nature, and it doesn’t restrict my expressiveness.
But I have no clue how to make a synth module blind-accessible - just giving me an API wouldn’t help. I would need to use the same assistive tech to be satisfied I did a good job. That goes beyond reasonable accommodation for a non-commercial hobbyist.
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.
A quick hack that could partially solve dark mode for all modules at once is to have an optional brightness invert shader at the end of the rendering chain, then everyone could just make a light version. Of course this isn’t as good as designing dark panels specifically but works well with for example the Fundamental modules imo.
Having something like this would be useful for running all sorts of post-processig effects geared towards accessibility like converting/restricting certain hues for different types of colourblindnesses or changing contrast etc.
”?
seal of quality 