Twine and accessibility (blind players)

Please specify version and format if asking for help, or apply optional tags above:
Twine Version:2
Story Format: 3.1

Hey all,

I would like to know whether Twine stories are accessible to blind players. I ran a story on a mac with Apple’s “speech” feature (not voice-over, though, because it’s super complicated to configure). And I also did the same with voice-over, on the iPhone—again, not very confident about the configurations I have.

It seems to work okay, except for hidden hooks, which appear after the player clicks on links. The voice-over doesn’t read them—or I’m not doing it properly. Does anyone know if including hidden hooks renders a Twine game inaccessible to blind players?


1 Like

As far as I’m aware, of the two main story formats (Harlowe and SugarCube) only SugarCube has had any ARIA (Accessibility) support deliberately added to it. I don’t know if that support includes speech.

I just gave it a whirl on Voiceover on Safari and was not impressed. I was able to access all the text with a screen reader but the links between passages weren’t actually links (as in <a />) so it was very hard to tell what the choices were. This would be easy for devs to fix though.

Surprisingly, the (link:) macro worked pretty well, but that’s only because the content appeared after where the link was. I think a hidden hook would display correctly but there’d be no way to know that another part of the page changed.

As a side note, sections using the (live:) macro were a big problem, as the cursor would jump to the top of the section every time the live area refreshed.

Overall, I don’t believe it’s possible to author content accessibility in Twine, but if the page link issue were fixed and an author didn’t use some of the dynamic content macros, then a Twine story could be accessible. It’s a pity because this medium really should be accessible to everyone.


Based on the syntax of the macros you mentioned it appears you were testing Harlowe, and not “Twine” (the GUI application) or the other Story Formats that application includes. So while your thoughtful observations at correct regarding Harlowe they may not be so for the other story formats.

As I stated earlier, (as far as I recall) only SugarCube has had any ARIA (Accessibility) support deliberately added to it.

Yes, thanks @Greyelf

It does sound like I mean Harlowe and not Twine. I’ve only used Twine with Harlowe so I wasn’t quite sure where one stopped and the other started. Also, OP mentioned story format 3.1 which I think means Harlowe 3.1.

Do you have a good story for me to test SugarCube for accessibility? I’m curious how well it does.

Have you seen the IFTF’s accessibility testing report? At the end of that document (just above the credits) there are links to the small Inform 7, Twine/Harlowe and Twine/SugarCube games that they used for testing.

It has been a while, so I don’t remember how many features they exercised, but at least it’s a small thing that you know was written in SugarCube.

At the other end of the spectrum…let’s see. Heretic’s Hope has a bunch of fancy styling, and…it uses cycling links, but I’m not sure it ever reveals hidden text.

Chuk and the Arena was also SugarCube. It used colored text fairly extensively, but only as a reminder: objects are always described as being a certain color as well.


In addition to what other people have said, it’s also about how you make your game.

In most cases, accessibility issues are more likely to come from the developer’s design decisions, than from the story format itself, though it can contribute, and I would agree that SugarCube is the better story format for accessibility. However, you can make the defaults in a story format extremely disabled-friendly, but if the developer ignores/doesn’t care about accessibility standards, then the end result can still be a pretty poor experience for people with visual, auditory, physical, and/or cognitive impairments.

On the plus side, developing in HTML with Twine means that you have access to all sorts of online accessibility testers, which can help you test individual pages, custom elements, and expose general HTML problems, and even browser extensions (such as the axe - Web Accessibility Testing extension (+Firefox)), which work better for testing passages.

So, while an accessibility-friendly story format is a good first step, the majority of the effort in remaining accessible lies in the hands of the developer and their design decisions.

Anyways, if you need any pointers with SugarCube and accessibility, feel free to ask. I’ve been doing a lot of research in that area and I’m pretty familiar with the SugarCube story format.

Good luck with your project! :smiley:


I can confirm that Twine stories created with Harlowe are inaccessible on Windows (using Narrator and NVDA), Mac OS X (using VoiceOver), and on Linux (using Orca. Of course, neither is the Twine application itself, which has honestly been the case sinse its creation. I would like to see Harlowe change their links to elements, as would I like to see Twine become more accessible to the visually impaired.


I suggest you add a related Issue to the project’s BitBucket repository, as I’m uncertain if that story format’s developer visits this forum…