Suggestions for Inform IDE accessibility improvements?

Thalor mentioned that the Inform IDE is difficult to read in bright mode and, in Windows at least, seems to lack a dark mode.

Are there any other accessibility issues with the Inform IDEs that could be gathered here? One thing I thought of is that I’m not sure how accessible the Index is.

I have no official role in developing Inform, I’m just trying to gather some suggestions here. (I might file them as a bug when the Inform 7 bugtracker is back up; currently the Mantis tracker appears to be down, and there’s a note on the home page saying that they’re migrating it to Jira.)


I’ve got a hell of a lot on this topic, but I’ll try to keep it a two cents kind of deal.

I’ve been told that most screen reader users on Mac don’t even bother with the IDE because of inaccessibility. As for the Windows IDE, there are many things which could be improved for screen readers, but the biggest bugs, at least for me, are in the story and index tabs.

In the story tab, the IDE does not report back to a screen reader. When typing test commands into my game, I have to manually scroll up to the result and read it. The desired behaviour would be to have it automatically read when the user presses return.

Basically whenever I want to test my game I have to release it and play it in an interpreter, which isn’t accessible by default either (obviously not the fault or concern of the Inform devs!).

In the index tab, there is practically no layout. I mean there is, but it’s entirely visual. Screen readers pay attention to the elements that comprise anything on screen, and they provide a way for users to navigate between them. For example, on the page for this post, I can jump between posts with the ‘a’ key, because each is contained in an “article” element. I can flick through links with ‘k’, if the search box were not collapsed I would be able to jump to it with ‘e’ for “edit”, headings are ‘h’, etc.

This is not because of specialty code, this page is coded properly in HTML 5, and that’s what my screen reader is looking at. Much of the Inform 7 IDE is a web app, and it could easily do this too. Things like properly marked up tables, page sections under headings, would make a world of difference when trying to use the index.

There are a great deal of other small annoyances that I’ve just sort of had to get used to, but I’ve seen less experienced screen reader users be discouraged by the interface. And obviously such users aren’t going to feel like compiling the games from the command line themselves is a simpler solution.


Thanks for the input!

I’ve just written some tips on how to get the most out of the IDE in its present state, using the NVDA screen reader. I apologize if this isn’t the place for that information. The information itself is here, and there is also a discussion.


Also, one thing I’ve never been able to use was the Skein. I honestly have no idea what it does because my screen reader (I’m on NVDA, as well) just says “unknown” and there are no interface elements I can interact with.

The Skein is a weird thing. To be honest I’ve never really used it. What it does is keep track of test plays and commands entered as a flowchart kind of like butterfly-effect transcripting. So if you test in the IDE with commands LOOK. INVENTORY. GO WEST. The skein will show three nodes of those commands in order. If you test again and instead enter LOOK. INVENTORY. GO EAST. the skein will show a branch in the third node showing two different paths the transcript took.

I personally never got the hang of it, but I’m sure there are people who love it and find it invaluable for testing. I suppose one advantage is you can click any node and select “play to here” to follow that strand in the skein to jump ahead without typing in all the previous commands. So the closest description is “interactive transcript”. In reality, the multitude of choices in parser means you’ve got this parallel-universe thing going on where the skein quickly becomes a mess of multiple transcripts. I’ve seen tech issues where the solution was “delete the skein” as if it might perhaps cause memory problems, but that might just be my misunderstanding of how it actually works.


Yeah. I’m in the same boat of ‘I’d like to use it, but, ehh, it just doesn’t work out.’

In the context of screenreaders, a lack of actual visualisation (onscreen) isn’t a problem at first, uh, glance. But when I read Hanon’s post, it occurred to me that this problem of recording branches in a workable way is the same onscreen and in the mind.

People who write with Twine have said there’s ultimately no good way to track it all onscreen. The Skein has the same problem, graphically – all the branches create a tree which is too much of a huge mess to use. Without a screenreader, you have to scroll around like crazy to see them all, and they stretch across, say, ten screen’s worth of real estate. So, unfortunately, it’s trying to help you deal with all these branches in your mind but it has trouble because it’s hard enough to deal with them all onscreen.

However… if we set aside trying to use the Skein to help program the adventure, the last thing Hanon mentioned is potentially important for all users, whether they ever wanted to use the Skein or not:

The Skein is always building itself as you test. You can’t turn it off. And the branches build up. I’ve experienced the following symptom myself: The skein record can become so huge it starts slowing down the IDE. Admittedly this can take months. But if you go for months building and testing your game without clearing out the Skein, this could happen to you. I came to the forum and found the solution was indeed to delete all the contents of the Skein, which is achieved by right-clicking the topmost knot in the Skein (which will bear the name of your Inform game file), and choosing the option ‘Delete all threads from here.’

Actually doing this can be fraught, too. I’ve had crashes after doing it, usually if I delete while playing, then continue to play. The Skein seems to get confused, presumably because the path it was on has gone. So, one needn’t do this very often, but when doing it, my practice is:

(a) Save my game file in case of a crash now
(b) Delete the contents of the skein by right-clicking the top row and saying ‘Delete threads from here’
(c) Save my game file again now that it has a nice, empty Skein
(d) Quit Inform and reopen my game file. Now I’m out of the danger zone

So, I hope that in a Screenreader, if you do open the Skein, you would start on that top knot. If you do, I figure you can use that to purge your Skein as per the preceding steps.


1 Like

I had a play around to see if I could clear the Skein from within the app. While it’s possible to right click the unlabeled graphic which represents the Skein, it’s not possible to locate the top knot with a screen reader. You could use the scroll bar, but it’s a little jumpy. However, if you don’t care about the Skein at all, it’s possible to get rid of it by deleting the “Skein.skein” file in the root of your project’s directory. Note that if you do this, Inform won’t re-create it when you start testing again, at least on my setup. So if you hope one day to use it (sighted or no) you may want to keep it somewhere.