Any interest in an accessibility guide?

nicolem

So as to not TOTALLY hijack this thread, I thought I'd move over here.

Is there any interest in a Twine accessibility project? Perhaps some kind of best-practices guide addressing issues of photosensitivity, contrast, font size, color blindness, etc? It'd be nice to have a drop-in set of JavaScript and CSS that authors could employ to at least have some kind of fallback.

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.

Pneuma

That sounds great, I was looking into text-to-speech capabilities as I came across the Speech Module tags in CSS while I was rabbit-holing to pretty up my Twine game, but I was disappointed to find that this was not implemented in any available browsers yet.

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.

rosencrantz

I would be interested! I like playing with CSS and all, but I am pro-accessibility. Anything to make it easier to create accessible games would be great!

kookidooki

Hello @nicolem and everyone,

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!

dacharya64

Sounds great!

greyelf

I think this is an excellent idea!

kookidooki wrote: »

Let's make Twine fully accessible!

I believe what you meant to say is "Let's make one of the Twine story formats fully accessible!" because to implement full accessible may/will require changing what HTML the built-in Javascript engine dynamic generates.

My suggestion would be to start with either the SugarCube 2 or Snowman story format as your basis and then to determine what CSS and Javascript changes are requires to make it more accessible.

A link that may help: An overview of accessible web applications and widgets

kookidooki

@greyelf, thanks for that link and advice, it's a great start! Makes sense.

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..

:-)

kookidooki

Dear All,

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.

So, I presume I have to abandon learning TwineScript (i.e. Harlowe) and switch over to learning HTML, CSS and JavaScript (along with the accessibility semantics that go along with all of these) in order to make a Twine game?

If that's so, will start the process.

Claretta

You only need to learn those if you want to do more advanced things like change the game's appearance substantially. And even then, CSS is mostly what you want to know since you can just copy paste other people's JavaScript. SugarCube has its own documentation: http://www.motoslave.net/sugarcube/

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.

kookidooki

That's great, thanks for that link too!! So, that's the format I used with Twine 1.4.2 (SugarCube). Will switch over now to SugarCube exclusively.

kookidooki

Just one last question for now - I guess I can go to all of those resources online that show you how to do certain things in Twine 1.4.2 -because they are using SugarCube as their default (or no?)

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).

TheMadExile

There are a few minor differences between SugarCube for Twine 1 and Twine 2, these largely revolve around special passages and tags (see SugarCube Special Names for more info). Beyond those differences, all of the standard SugarCube documentation still applies.

Claretta

kookidooki wrote: »

Just one last question for now - I guess I can go to all of those resources online that show you how to do certain things in Twine 1.4.2 -because they are using SugarCube as their default (or no?)

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.

kookidooki

So everyone...

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.

greyelf

One of the issues with Harlowe and accessibility is that it uses custom HTML elements and the Reader software may not understand what they represent, this was one of the reasons I suggested using a different story format.

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.

Claretta

kookidooki wrote: »

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..)

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.

To this day, Harlowe still confuses the hell out of me and I consider myself an advanced Twine user by now, using a load of JavaScript and CSS.

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.

kookidooki

No, I am not trumpeting one story format, but Twine is - they are trumpeting Harlowe as "easier to use" - it's in their website. This is what got me started on Harlowe. I was using SugarCube to start in Twine 1.4.2.

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!

Claretta

Well, don't switch to SugarCube just on my account please, use what feels right for you. I express my opinions strongly but I don't pretend they are some universal truth.

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.

kookidooki

Ok, I get your point, you are totally right on that front. I won't get started on my Twine 2 troubles btw.

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!

TheMadExile

kookidooki wrote: »

No, I am not trumpeting one story format, but Twine is - they are trumpeting Harlowe as "easier to use" - it's in their website.

Clarification: That's not Twine's website, it's Harlowe's (i.e. it's the opinion of Harlowe's author). As far as I know, CK has, wisely, not weighed in on the matter. I could put the same thing on SugarCube's, it wouldn't make it any more true in general.

People like what they like. There is no "best" format.

kookidooki

Yes, but there's misinformation out there. Twine 2.0 (Harlowe) sets itself up as better, especially for beginners and novices who don't know much about the differences between 1 and 2, with regard to designing for accessibility. The fact that there are so many inconsistencies between 2 and 1 is a shame. 2 is supposed to be an improvement on 1, it isn't supposed to regress. Having said all of the above, given the frustrations i have with Twine in general, I still love it to death.

Thanks for clarifying. All of this information is very valuable. We shall put it in the future wiki on Twine accessibility. :-)

greyelf

I believe that there may be some confusion, when they say "Twine 2 was designing for accessibility" I believe they meant "easier for people to access the application" because you don't have to download and install it like you do with Twine 1.

The word "accessibility" has more than one meaning in regards to applications.

greyelf

AvaJarvis has posted Hacking Accessibility into Twine which currently covers adding some accessibility features to Snowman 2

AvaJarvis

I'm very interested in this subject. As indicated by greyelf above, I had to do a few funky things in Snowman. I also listed the limitations I found with the other story formats.

For people who are interested in accessibility testing, there are Chrome extensions and WAVE for starters. I do agree that making a set of Javascripts and CSS files available would be a good idea.

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.

TheMadExile

SugarCube 2 should be significantly more accessible. I've currently got a lot of accessibility work done in my local repo (everything should now be focusable and interactable, with both mouse and keyboard, and I've added more aria attributes), which will probably make it into the next pre-release, whenever it comes out. I've still got a few major hurdles to overcome, the stickiest being disabling the rest of the page when a dialog is open (not sure how I'm going to solve that one).

AvaJarvis

@TheMadExile - Awesome to hear! I'm very excited for the next release. I'll wait for whenever it happens -- it'll probably happen before I finish my current long work!

L

Just want to make a few brief remarks:

* 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.