Almost out of topic, but I’ve seen several people proposing to remove ScIDE, and I can’t find any good reason to do so (but moving it as an optional tool when advanced users don’t need it would be good indeed).
As a self-taught programmer (who studied literature, then music, and almost never touched a computer till mid twenties), I was really happy to use ScIDE at some point. The first contact I had with an IDE was Sonic-Pi, and it only had auto-completion and integrated documentation. But I was really happy it had that. It was new to me. Then, when I discovered ScIDE, that was my first contact with a complicated IDE that allowed me to get deeper into code manipulation. Now that I’ve discovered Emacs and equivalent, yeah, that’s even more powerful and everything. But it took me time to understand what it really allows.
Many people in this forum are powerusers (and almost superpowerusers, I’d say). I think they don’t see the pedagogic quality SuperCollider is made of anymore, because it’s long behind them. But ScIDE is really good for beginners. This tool works really well for students that are novice in code, and do not have access to programming courses (e.g. art students in my town). It lacks advanced features because it retains simplicity. And that’s what those users need to get started.
Also, jrsurge has mentioned interest into maintaining it, and so do I even if I lack the technical competences for now.
Since we’re discussing inclusivity, I think we should also consider the technical knowledge as part of the accessibility problem, and I’d like to point out that ScIDE seems, at least to me, to be designed in that way.
Back to the original topic, I think for now the quickest solution is to have a specific setup for the person. Maybe a Vim/Emacs setup, for example, would be easy to configure, and easy to read due the text-only nature of those editors ? I fear I lack the competence to answer this question in a smart manner…
Having feedback from her experience would be helpful for us to understand what we didn’t think about in the first place.
And documenting the setup you are going to use online might be at least something to have if the situation happens again ?
For SC, in the future, I think we should list disabilities that interfere with the software usage, and see if we have a way to negate or reduce them.
Simplest example I can think of is to implement a colour-blind mode, which would be the default setting, so that syntax colouration/visual feedback/etc only use colours that are distinguishable by colour-blind people. Nowadays, most video-games include this option, for example.
Best thing to do would be to have a menu on top of the editor, which allows to quickly and easily select a list of pathologies, that adapts the interface automatically according to the needs.
I once saw a presentation about a software that ingested websites, and added such an automatic menu, which would change fonts automatically for dyslexic persons, etc. It could also render a low carbon footprint version of the site automatically. But I think such software aren’t free to copy…
Accessibility are usually defined by legal norms. We should find such documents, then point out everything we don’t do according to the norm, and implement solutions until the norm is respected. That’s a huge work tho.