SC for visually-impaired coders

Dear all

I have given a FluCoMa workshop yesterday and one attendee was visually impaired. I was stuck on how much SC (and my whole thinking) still revolves around visual feedback. The multiple windows to start with. And the colour coding of it all (grey green yellow server status)

I lived and I learnt.

Now I wonder if there is any pointers towards good practice for SuperColliding for the visually impaired. Especially removing all gui and getting all feedback in a single window for instance. or other things. Weā€™re going to do a tutorial and customisation for her on Monday but I wondered if someone has a list somewhere that would help me not-reinvent-the-wheel.

there is this old GitHub issue:

and thatā€™s what I found. No worries if nothing, Iā€™ll share what we find.

I was going to suggest NeoVim with TalonVoice although VSCode might be better! I know @scztt is hard at work on VSCode implementationā€¦ (O/T but I think the IDE has its use though).

1 Like

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.

The reason is, it is unmaintained and that is unlikely to change because there isnā€™t the human power for it. Consider that itā€™s been over a year since this thread was started: Wishlist for the IDE and not a single one of those features has been implemented, in fact there hasnā€™t been a single commit in that part of the codebase since February 2022.

Still, it works, and as said, pretty well for beginners.
SC_SynthDef.h wasnā€™t modified for the last 4 years, but I still would like to keep it as is inside the project.

jrsurge mentioned, two weeks ago, that he would like to implement some of the functionalities that were mentioned in the wishlist, but that he would need to upgrade QT to v6. Whatā€™s stopping him are the infamous backward compatibility issues.

Here is another reason. We need to remain relevant to the next generation of users. The youths are very likely to have taken a coding class at some point and almost any language they learn will have support in something like VSCode. VSCode is amazing and robust and maintained. So, if people have any coding experience at all, they already know and are familiar with editors like that. So if you want to teach them SC, then they are already in a familiar environment. It doesnā€™t take much to convince them that SC is a legit language because it works like all the other ones in the same coding environment. ALSO, placing SC in these existing environments shows that it is in a broader ecosystem of languages. It places plugin design and language development within the same environment as SC coding, so it will encourage more people to do those things. It will also make it easy for people who are learning programming for the first time to branch out into other languages. I think it is a win win win.

Sam

My students came from art school and supercollider was universally their first exposure to coding. We need to make sure that onboarding for this kind of user is straightforward.

The appropriate comparison would be to the server subproject, you can see itā€™s much more active by comparison despite the lack of a 60-some-comment thread of feature requests : History for server - supercollider/supercollider Ā· GitHub

+1 to everything Sam said as well.

Bringing it back to the original topic, if this editor worked ā€œquite wellā€, this thread would not exist. Weā€™re not talking about how useful it is for you and other sighted people ā€“ it is not working for people using screen readers and this is a major problem for any software. The focus should be on how that situation can be improved, and I would say by making integration with other editors better since this projectā€™s editor is unlikely to see any meaningful change under the present circumstances.

Can you code all day long in it without ever touching a mouse (I donā€™t use it)?

A friend of me is blind, she uses various audio programs. What I know, Sox and Ecasound from the command-line or vim. Csound also vim. SC, probably vim. Python for programming.

In general, any form of ā€œclutterā€ distracts, takes time. Things that are slow annoys, even more than it does us.

OS is windows as it has the best support for ability related tool.

I never looked under the hood. Are all the tools in the IDE built in it or do the data all come from ā€œa serverā€?

If I get it correct, VS Code is published under a non-FLOSS license, and
as such it should not become a a part that SC will depend on in the
future.

2 Likes

Lovely people, thanks for all of this. i didnā€™t want to start anything like that, I just try to help a student. but hey, SCIDE and VSCode integration can both exist if sub-community are happy to support them. the latter seems more appropriate for my use case.

OK Iā€™ll explore the current (cumbersome it seems) VSCode integration and contribute with the student to flag our hurdles in this thread.

I donā€™t have a ton of capacity to dig deep into accessibility topics in VSCode right now (still working on basic functionality), but please create issues (or one meta-issue) with any blockers for visually impaired users. Iā€™d definitely still like to jump on anything thatā€™s a quick fix - and in general Iā€™ve done a modest amount of development work for VI usage and would be very interested in improving this in the future.

Donā€™t worry I donā€™t expect to. Iā€™m going to make a list and we can see how tackle-able it is.

thanks for your help
p

1 Like

I think you might be able to understand French language ? Those kind of resources are harder to find for me in English.

Here in France, the Framasoft association has worked a bit on the accessibility problems when it comes to computer usage.

They have listed a few software designed to ease accessibility. This is mostly web-oriented, but there seems to be a ā€˜colour-blind simulatorā€™ that allows to check if the current graphical context is compatible with the handicap. Thereā€™s also a tool that validates if the contrast between two colours is enough to be clearly distinguishable. I think they used it in their graphical chart (if you hover the coloured dots, it shows an ā€˜accessibility scoreā€™ for the given colour).

In English :

Hereā€™s the Web Content Accessibility Guidelines. This is the international standard defined by W3C. Rates between ā€˜A and AAAā€™.

Hereā€™s EN 301 549 V2.1.2, Europeā€™s legal response to this problem.

En effet :slight_smile:

Thanks for those resources. As soon as I get VSCode working for me, Iā€™ll meet with my student and get a clear, text-only how-to-install and then get to make some VI-friendly FluCoMa tutorials.

more soon

p