Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Twine Accessiblility

Howdy All,
I used Twine to write an activity for a forensics science course because I assumed (wrongly :-[) that it would output HTML that was accessible. Now disillusioned, I know that I can use another software to recreate the activity but I wanted to see if the difficulties could be overcome. I wanted to know if there was any way to add a tabindex to each of the passage links using javascript.

Thanks

Comments

  • Can anyone address: what are the issues with accessibility with Twine, and what can a user do to overcome them?

    Thanks!

    @anthkris09, you could use the nav-index CSS property (i.e, just add to the CSS for the passage link classes), but it looks like support is still very poor for that. A quick look at stackoverflow suggests that tabindex=0 applied to all links will order them in source-code order. So the following, added to your PassageDone special passage, should give everything a tab order:
    <<script>>
    $("#passages a").attr("tabindex", 0);
    <</script>>
    Note that I use SugarCube, and there may be differences if you are using a different header.
  • Howdy Erik,
    From what I can see the major issues with accessibility in Twine are that:
    A. The passages display in the same window. This means that a screen reader reads the page once and then stops. It doesn't recognize that the text on the page has changed. It would be good if there was a way to tell Twine to build out the passages/links in new files, instead of essentially showing/hiding passages all in the same file.
    B. There is no inherent skipnav link. Of course this can be added after the story is built but it would be better to have it built in.
    C. There is no way to set tab order/reading order on links. Right now, the only links that you can tab to are the reset and bookmark links.

    Thanks for the help. It works a treat in SugarCube but any idea on how to modify it for SugarCane?
  • This should work in all headers: (put that in a script tagged passage)

    postrender["addTabindexes"] = function (content) {
    var links = content.querySelectorAll("a");
    for (var i = 0, len = links.length; i < len; i++) {
    links[i].setAttribute("tabindex", 0);
    }
    };
  • Thanks! That works.

    Unfortunately, after continuing to think through all of the issues, I think they are insurmountable in the timeframe I have. So I'll have to rebuild somewhere else. I sincerely hope the coders design accessibility features into Twine in the future. I'm pretty disappointed. :(
  • anthkris09 wrote:

    A. The passages display in the same window. This means that a screen reader reads the page once and then stops. It doesn't recognize that the text on the page has changed. It would be good if there was a way to tell Twine to build out the passages/links in new files, instead of essentially showing/hiding passages all in the same file.

    Hrm, I have to say this sounds to me like a problem with screen readers. Dynamic loading of content into a frame (whether from separate files or rendered from data a la Twine) is here to stay. Does anyone know if this issue is surmountable?

    anthkris09 wrote:

    B. There is no inherent skipnav link. Of course this can be added after the story is built but it would be better to have it built in.
    C. There is no way to set tab order/reading order on links. Right now, the only links that you can tab to are the reset and bookmark links.

    These two seem pretty easily fixed right now by users. (In fact: On Chrome and Firefox, at least, the links in my passage text are tabbable out of the box with SugarCube.)
  • There's definitely more to it than that. I'm no expert. But I noticed that even when the tab order was there, I couldn't "click" on the link using the enter key. This I suppose would require more javascript.
    Screen readers are changing, but slowly. Still, I'm not sure it's fair to say that screen readers should just get dynamic loading. I think it's incumbent on all of us to use universal design principles.
  • Activating a link with enter works for me.
  • anthkris09 wrote:

    A. The passages display in the same window. This means that a screen reader reads the page once and then stops. It doesn't recognize that the text on the page has changed. It would be good if there was a way to tell Twine to build out the passages/links in new files, instead of essentially showing/hiding passages all in the same file.
    Pardon me for focusing exclusively on this point, but permit me to make a few remarks. The "single HTML file" aspect of Twine is one of its guiding design principles, for much the same reasons that TiddlyWiki extolls it. It promotes A) file portability - users need only upload one HTML file to their hosting service, copy it to a drive, move it around in their file systems, etc., and be guaranteed that the whole game is in there; B) file integrity - parts of the game can't go missing or fail to load on a faulty connection - when there's just one file, it's all or nothing; C) reverse-compilation: the single HTML file can be rebuilt easily from ; D) symmetry with other "media formats" - just as an MP3 doesn't need a folder of loose files in order to "work", and neither does a PDF, then so too does a Twine videogame.

    Nevertheless, I understand the world has demands outside of these concerns, and that practicality must, in some circumstances, trump ideals. I believe a new "story format" that actually outputs the story as a 90s-hypertext "folder of HTML files", at the expense of all the "stateful" macros and functions (<<set>>, visited(), etc.) being unavailable, could be developed. Although, it would require some significant alterations to Twine's internal compilation process to accomodate this - it's a bit of a radical change.
  • The new ARIA standards are attempting to allow this sort of thing to be understandable to screen readers, because, as Erik points out, it's not going away. They aren't perfect because they aren't supported everywhere right now, but the point is that there are standards in place that could be used to make Twine output more accessible. But that still requires thinking of those universal design principles.
  • What exactly is the goal? To make it possible to use Twine to create specific content that is screen reader friendly or to make Twine's default output more screen reader friendly?
Sign In or Register to comment.