So as to not TOTALLY hijack this thread
, I thought I'd move over here.
It sounds like JAWS is pretty much a lost cause with the way Twine works, but perhaps there are other screen reader options too?
Also: I am happy to take any "yeah, okay" replies or silence as permission to just go ahead and add this all to the Twinery wiki.
It would be great if there was a wiki people could collaborate on in order to make our IF more available to everyone, as I think that IF is one of the few types of game to cross multiple genre's/sectors/clicks, and thus should be open to everyone possible.
Also some way of getting speech out, in a way that can be followed on-screen, could really help with early-child development and additional language programs that could appeal to a wider audience.
I would be also interested in this project - I was hoping to post another thread on advocating Twine accessibility for both designers and players and found you - which is great.
Perhaps we can start a Wiki page and an archive of code (a public Google Docs) that helps make Twine accessible?
So, I am not familiar with JAWS but was hoping to troubleshoot my Twine creations with OS X's VoiceOver.
Any other ideas would be welcome on this front.
Let's make Twine fully accessible!
A link that may help: An overview of accessible web applications and widgets
I have to try this myself and test it with a screen reader first and then will post here to let everyone know what comes of it. Will try SugarCube 2.
But in the meantime, we should start a Wiki page and start compiling all of this important information...
I am trying to start one up - will let you know how that goes..
So, I am just going to start this thread and keep writing about my experiences trying to make an existing Twine document accessible. Maybe you can pitch in with suggestions if I am omitting something or doing something wrong. ;-)
First of all, when I switch over from Harlowe (my preferred format) to SugarCube2 - I see that some of my tags (as shown on the http://twine2.neocities.org) do not work in SugarCube2.
This hook doesn't translate in SugarCube2. (text-color: #CC0000) [some text here]
So, I guess, the information on http://twine2.neocities.org is for Harlowe exclusively? Too bad Harlowe is not designed for accessibility because there is all this info online on how to code using it, especially for beginners who have never made a Twine game.
If that's so, will start the process.
Overall I prefer SugarCube since I think its macros are easier to understand (the Harlowe format of mixing a load of () and  in macros seems to catch many people out), it has more features, and works with the more robust 1.4.2 version of Twine.
In other words, any online documentation on how to work with Twine 1.4.2 will work in SugarCube in Twine 2.0. right?
All I have to do now is to add the accessibility semantics to SugarCube (which is another learning process for me).
Not entirely. Many guides online are for the SugarCane format, which is very similar and uses many of the same macros, but has a bit less functionality.
This is the thing. The reason why i switched to Twine 2.0's "default" format Harlowe is because I read this:
"It's been redesigned from the ground up, and I hope you'll find it better and easier to use than Twine 1's" http://twine2.neocities.org/
And in fact, I DO find the Harlowe syntax and markup a lot more elegant and streamlined than Twine 1.0.
So, when you're teaching this to beginners who have ZERO web design/development or Twine experience, it's really easier to teach Harlowe than SugarCube. But then, for gameplay, Harlowe is inaccessible. (Well, i have learned that adding 'title' tags instead of 'alt' tags to images works in Harlowe in my browser...that's all I have tested so far..)
Basically, in Harlowe, the alt tag does not work: <img src="smiley.gif" alt="Smiley face"> When i change it to 'title' instead of 'alt', it works in my browser (but have to check on accessibility experts on this).
So, it's trial and error for me, and making a fool of myself at times :-P
Thanks for all your feedback. Appreciate it lots! You are awesome.
eg. tw-passage, tw-sidebar, tw-link, tw-hook
There are ways to get around the custom element issue as explained by this article.
note: The article is written in relation to a product named polymer but contains general information relevant to the issue.
I dunno. I started with Harlowe at first but it confused the hell out of me. I picked SugarCube up instantly after I switched. I just understood the <<if>></if>> macro structure implicitly.
I don't think it's as simple as saying "A new user will find *this* to be easier". Because maybe they won't. Different people understand different things. Different people want to *do* different things in their stories.
I think it's great that Twine users have a choice of story formats, so Harlowe is worthwhile on that count, but I really disagree with trumpeting one story format over another on accessibility grounds, as that is making assumptions about the audience that may not be true.
For myself, Harlowe is easier, so not sure for others. Plus, if I am imparting my knowledge to others, Harlowe is easier to teach, but will be switching to SugarCube now.
Twine says: "It's been redesigned from the ground up, and I hope you'll find it better and easier to use than Twine 1's."
Anyway, thank you to both @greyelf and @Claretta for the clarifications, helps!
But Twine 2 overall... I just don't know. There are so many features of the Twine 1.4.2 desktop program I like that I feel the browser-only Twine 2 is clunky in many regards. I think there are many new users who would feel the same and prefer the Twine 1.4.2 workspace.
Just try editing a long CSS passage in Twine 2 instead of Twine 1 and you might see what I mean. Just the simple ability to expand the passage to fullscreen to work on is missing in Twine 2. That's an accessibility issue in itself. The same thing that is made easy by using a fullscreen in 1.4.2 becomes a scrolling nightmare in Twine 2.
It's just that I've been involved in teaching Twine to people who are beginners. I wanted to have my cake and eat it too -teach Harlowe (I spent learning it like crazy since it came out in Dec) and be able to design for accessibility too. @greyelf's link on accessibility is a great resource - ok will try that.
Anyway, more research needed on my front. :-) All is cool!
People like what they like. There is no "best" format.
Thanks for clarifying. All of this information is very valuable. We shall put it in the future wiki on Twine accessibility. :-)
The word "accessibility" has more than one meaning in regards to applications.
I love VoiceOver on the Mac. I've never used JAWS but am looking into investigating usability of my sites through it.
Additionally I am working on adding a way to set up options in Snowman 2 to easily set whether to use OpenDyslexic (a special font) or not.
I much prefer working in SugarCube or Harlowe than Snowman, but those have some intricate failings. I'd love to take a crack at fixing them or creating polyfills.
* When I wrote my Twine 2 information page, I was using terms such as "easier to use" exclusively to refer to the act of writing the story - that is, the syntax and macros. I'm sorry if this misled anyone in believing that this was referring to Twine 1's lack of user-accessibility in its HTML output - that regrettably wasn't my main focus of attention at the time.
* Awhile ago I added to what would eventually be the Harlowe 1.1.0 beta some code to make its <tw-link> elements keyboard-navigable, and, to my knowledge in Firefox and Chrome you can navigate and activate <tw-link>s and the back/forward icons using Tab and Enter keys. However, this is of course only one dimension of accessibility, and I do not currently, for instance, have any ARIA roles assigned to these elements by default. I hope to pursue and solve these issues in future Harlowe releases, heeding your feedback.