Hey, kudos to you for thinking about this! Background: I'm totally blind, have programmed for nearly 3 decades, kind of do the in and out of half a dozen languages thing these days. Today's favorites are Rust anywhere I can get away with it, Python because it runs in places where I need it (Home Assistant, Mycroft, etc.) and JavaScript because if I hold my nose and don't think too much about the atrocities I'm committing, I can run the same or similar code in various form factors. I'll try to give a few pointers. Note that these are specific to blindness, and specific to me. I don't claim to speak for the disabled population as a whole, as we're kind of a grab bag.
1. Indentation: Pretty much a solved problem at this point. If I were reading Python code line-by-line, my editor might speak something like (not sure if my newlines will make it, but imagine them where they should be):
def hello(world):
4 spaces print("Hello, world.")
4 spaces 1 tab 4 spaces print("What was I thinking when I indented this line?")
So I wouldn't worry too much about that. I've never had issues with an indentation-based language, and anyone blind who does likely just needs to change their tooling a bit. This is usually just a checkbox in the screen reader settings, so doesn't even usually require an editor/IDE change.
2. Avoid crazy symbols. Scala gave me some grief with this, with every library author having method names like %^&@^$# because I assume that set of symbols looks like performHttpRequest(...) in some visual way. I exaggerate a bit. Only a bit. Note that operator overloading is fine, at least from an accessibility perspective. It's when people decide that a series of connected punctuation symbols evokes the idea of making an HTTP request or opening an Option that I start to get annoyed.
3. Create good command line tooling. Rust has this nailed. I like how Rust's own installer just uses rustup under the hood, or at least I think it does, and every blog post advertising a new component also includes the rustup incantations to grab it. I assume the editor interfaces are as nice or nearly so. I guess the takeaway is, package your language installation tooling in a library so you can invoke it from the CLI, editor plugins, etc.
4. Put error messages at the bottom of stacktraces rather than the top. Python does this right, and everyone else gets it wrong[1]. Say you're running a compiler from your command line. You get an error, and your cursor lands on the input area, ready for a new command. As a screen reader user, you discover that error by entering your window's review mode and moving up. With JavaScript, Rust, and just about everything else, I have to arrow through the callstack in reverse as I move up the screen to the line containing the error. Python puts this error last, near the input cursor, so all you're doing is arrowing up a couple lines. It's a few seconds per error, but can add up immensely over the course of a day. NPM, infuriatingly, shows the error, followed by disclaimer text that the error isn't in NPM, then barfs up an NPM error just to confuse things. So any JS package I use that uses NPM for its scripting requires arrowing back through 2 stacktraces to find the original error. It's enough to drive me to drink.
I can probably come up with more, but I haven't finished my coffee yet. Perhaps that's a good thing...
1. Right and wrong are of course subjective. This is just one blind dude's opinion, take it for what it's worth.