Warning! Long reply alert!
Short answer: Ren’Py has quite a few features out of the box, some that are trivial to add, some that require a bit of programming (but nothing likely to daunt someone used to, say, Inform) and some that require substantial programming. However, none of the things I’ve described, as far as I know, require quite as much programming as some Ren’Py authors employ in order to make their visual novels graphically compelling (that, to my less experienced eye, is next door to magic).
To answer some of your latter points first, Ren’Py by default displays every choice, thus every exit. It’s possible to hide/reveal choices that can’t currently be taken, hide choices until some trigger is met, prioritise which choices are seen and hide the rest or do other tricks to obfuscate options. However, all of these are more complicated than the accessible choice of simply showing every option. (In theory it’s even possible to use a menu item to launch a parser or psuedo-parser, although that would be hilariously complicated to program.)
Objects are more difficult, largely because Ren’Py doesn’t assume any objects will be involved by default. These have to be programmed and described individually. If one wants those objects to be visible, one will need an inventory. (Budacanta has a “rucksack” facility for this; it’s straightforward enough to program the container. Rather more difficult is programming when items will be visible. Even more so if one would like to be able to use items manually in the inventory. The latter two elements don’t get much help from Ren’Py, although it is possible with canny use of the state-tracking). Making it visible at all times would require two separate user interface changes (one for the choice screens and another one for the rest), may not be compatible with self-voicing or screen-readers, and would cause user interface problems for sighted players in the typical mid-game inventory situation.
Ren’Py’s self-voicing will handle all visible text, although screen-readers’ ability to do likewise may vary (I’ve not figured out how to get NVDI to work with it).
Ren’Py does have some features out of the box that are helpful to accessibility. For example, the unlimited saves and auto-saves are built into the engine. It is able to do things like multiple controllers and self-voicing provided you don’t do anything that messes it up (Ren’Py allows a lot of flexibility for advanced users but one has to be careful not to lose benefits that are naturally there if one had just kept it simple).
Ren’Py has controller instructions out of the box, but not remapping, how-to instructions or tutorials. I’m still working on the remapping (at the moment, control profiles are the main delay), instructions on the first screen were as easy to program as any other choice text and the biggest issue with the tutorials was remembering to give the player the option to stop it and just play the game every so often 
Translations aren’t there straight out of the box, but there is a mechanism that simplifies a lot of the necessary effort. Provided, of course, that your translators follow your instructions. Remembering to describe all backgrounds’ essential features gets easier with practise. Things like the “continue” option on the start menu and “return to before the mistake” option have to be programmed in, using Ren’Py’s ability to keep state information to help with the background book-keeping.
Rollback exists but defaults to around a dozen screens, albeit changing that requires only a number and a mental note that for an intricate, large game (think tens of thousands of screens, possible if there’s either a very long linear narrative or multiple hard-as-nails puzzles with no external game length restrictions), the novel may stop working on some slower computers due to the buffer size. (Depending on Ren’Py version, it’s possible to target computers running Windows 98, Max OSX 10.3 or - with some jiggery-pokery on the part of the player - original iPads and the Android devices of 15 years ago). There’s no tradition of writing additional files for Ren’Py games, so the “about” text file is something I created on my own initiative.
Areas where Ren’Py struggles (especially compared to parser interpreters) include text and background flexibility (every additional option has to be programmed manually; the defaults are accessible but boring enough that any player familiar with the engine will notice and wonder why the default was kept). Visual novels also tend to have lots of animation in the sprites and Ren’Py doesn’t build in any sort of “off” switch for this. (Budacanta currently gets round this by having no sprites to animate; some other Ren’Py novels program a switch in the game menu that allows animations to be turned off and/or slowed down).
Accessible status bars are very difficult to do in Ren’Py, it turns out. While lots of people appear able to do graphical GUIs, getting graphical status bars to work properly with screen readers turns out to be complex, especially if (like Budacanta) there are plot reasons for it not to be constantly available. Hence why I have the inelegant but thematic and accessible method of incorporating them into the choice menu, omitting information that definitely isn’t relevant to the player for that choice menu.
The most challenging one so far has been the music off by instrument. In fact, I only got the idea it was possible because I happened to see some code Alaric on a Ren’Py development Discord server. The original intention was to block insect and spider sounds in Alaric’s game. I asked permission to use it for music control (since my game still hasn’t got any sound), he agreed and I ended up splitting my music into different instruments to make the concept possible. Obviously, once I have sounds, those are going to be blockable by sound type too, and I can see how to extend the concept to allowing users to select types of written content they’d rather not see. I think it is worth it because it gives a way for people concerned about phobias, anxiety or stress ways to engage with the IF that aren’t limited to “play something else”. I like the idea of modestly extending what “accessible” can mean in IF.
