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
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: Note that I use SugarCube, and there may be differences if you are using a different header.
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?
script
tagged passage)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.
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?
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.)
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.
WebAIM - Accessibility of Rich Internet Applications
WAI-ARIA Overview
Web Content Accessibility Guidelines (WCAG) 2.0
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.