I’m wondering what the screen reader experience is for Sugarcube. I’ve used a screen reader with it, but I’m specifically looking for perspectives from people who are daily screen reader users.
That is all, lol. Looking forward to reading replies. 
EDIT: Holy crap Twine gets a lot of traffic! I just posted this, and there’s already activity!
Unfortunately, less than optimal. I had to tweak my settings dialog to use drop down lists everywhere, because Josh found out that the screen reader did not mention whether a toggle was on or off. I also asked for screen reader feedback here on this forum but drew a blank. Maybe the screen reader community is not as big as I expected?
I’d say that out of the box it’s probably pretty good: I know at least one player finished the Spanish version of whoami using screen reader (I did not use special accessibility tags and the game has some non-linear text effects, so any merit is the engine’s).
From what I understand it is good out of the box, with most elements already having the correct labels and so on, as long as you’re not doing anything really funky with it, which I think is where Onno is having problems. I’ve only had to go out of my way to make things screenreader compatible when I was using timers and funky characters chosen for aesthetics, or using background colors to indicate something important, or using images. If you just want to do text with links and maybe some buttons, text entry boxes, and drop-down menus, you shouldn’t have to do much, if anything, to make it accessible .
True, I did a LOT of funky stuff with timed text, a canvas, and a custom StoryInterface. However where things went wrong was when I wanted to add the standard Settings dialog. I even tried to create a simple game with everything standard, no tweaking, just a settings dialog with two options. And the screen reader does not read out the option state. Go figure.(I’m using NVDA)
Ah, I see – I’ve never used the settings API so I can’t speak to that. It might be worth letting the SugarCube maintainer know that that’s not playing nicely with screenreaders; I do get the impression they care about that.
SugarCube is very accessible! In fact, it’s much more accessible than Harlowe, for example, because all of its links are actually… Links. Therefore, it’s not dependent on the screen reader detecting the presence of its links, as Harlowe is.
Has anyone opened an Issue on the SugarCube’s GitHub repository to let the story format’s Developer know about this Setting API’s Accessibility related limitation?
Yes the issue was raised 2 months ago after I mentioned it (by tmedwards as issue #368)