Potential visual accessibility changes to the doc to better depict the concepts of Rust?

[luckynumberke7in]

Language your translation is for: Visually impaired
URL to the repo where you're working: no repo yet, I'm in the investigation phase.

However, I'm planning on recording a true audiobook version of "The Book" as I have noticed there isn't any 1:1 that exists. In this idea I also had the idea of making the audiobook and audio / video combo to be released to youtube to be especially geared towards making Rust accessible to the visually impaired ( because I have prior experience producing audiobooks in this format ).

I created this post: https://users.rust-lang.org/t/best-way-to-describe-code-blocks-for-accessible-audio-book/108316/12

...and a wonderful rustacean had the idea of taking the concepts I learn about the describing Rust concepts and integrating them actually into the book. And potentially even integrating accessibility tips in VS Code or another potential editor to help bridge the gap in knowledge base?

Is this something I should consider pursuing?

As an additional context point, see the specific reddit video and post in the forum above.

It seems like there is a definite gap in general in programming accessibility resources, and I think we might have found the perfect way to help close that gap in the rust ecosystem!

This is all still very conceptual and open to input!

Thanks for reading and have a wonderful day :)

[chriskrycho]

As, I think, one of the people who has done the most thinking about “how to say Rust code in a way that doesn’t assume you are looking at it/can see it”, courtesy of my work on New Rustacean, I would be happy to have a discussion about this! I think the book itself probably does not need changes so much as you need a style guide and some additional introductory material for the audio content alone, which you could and should absolutely script for it.

One thing you should also consider as you are thinking about this is: audio specifically for visually impaired people might have different tradeoffs than audio for everyone, but which keeps visually impaired people especially in mind. The kind of “spelling out” you get from NVDA is not what you want for general audio content, for example. For example, if you have this code:

fn print_it<T: Display>(to_print: T) {
}

You want to say “a function named ‘print it’ generic over T, where T is constrained to be Display, which takes a parameter named ‘to print’ of type T, and has no return type”, not eff en space print underscore it open angle bracket T colon Display closing angle bracket open parentheses to underscore print colon space T close parentheses space”. (That’s exaggerated to make the point; a screen reader can be configured to be smarter than that, but I trust it gets the idea across!) To make that work, you will need material that *does* “spell it out” fully the first time, and then explains that from now on you will pronounce fn foo` as “a function named foo”, etc.