Parser games aren’t off the hook either. As people start incorporating visual elements into parser games (like the map in “Map”), it’s important to keep in mind that not everyone is going to be working with the same setup – whether in terms of their computing device or their body – as you are. If a visual element is going to be central to the game, these technical issues should be given great consideration. I think in the excitement this often gets left behind, which, as Sarah says, is kind of disappointing in a medium whose text-based nature had previously made it relatively accessible on that front.
I looked into this while I was writing Birdland and it seems like Twine html is pretty unusual. It does a lot of stuff that screen readers just aren’t made to handle.
I’m curious, though. Are there any accessible choice based systems besides ChoiceScript? And do all ChoiceScript games work with screen readers?
Thanks, I’ve been lurking here for a few weeks so thought I’d better sign up to comment on what has been a brilliant competition (despite my complaining!)
I know nothing about programming, for all I know my laptop is kept running by the tiny fairies that live in it. All this means that although I can moan about Twine I have absolutely no useful suggestions to offer as to how it can be made more accessible! All I can say is that, while Choicescript’s check boxes work fine my screen-reader (which I believe is one of the most widely used) just can’t recognise any of the text in a Twine game, all it can usually read is the title although it will occasionally read an entire game including all the code as being on one page so you can read (rather than play) the game if you can slog through lines of code to get to the bits of game text which is not exactly an immersive experience!
Lux, I had played and finished ‘Map’ but hadn’t realised it contained a dynamic map, this would probably have helped cut out the large amount of aimless wandering which was necessary to find the new rooms. I can completely understand including graphics when they enhance the look or mood of the game, it’s just frustrating when the graphics are necessary or extremely helpful for finishing the game.
BPHennessy, thanks for clarifying the Twine thing a bit. I have played a few ChoiceScript games and they all seem fine which I think is because of the simple check box structure, my screen reader (Jaws) has no trouble with check boxes and as far as I have seen ChoiceScript doesn’t have any more complicated mechanics which is probably quite limiting for authors wanting to experiment with game formats but I do find it very user-friendly.
By the way, I was sorry not to be able to play ‘Birdland’, from the reviews I read it really sounds just my cup of tea!
The thing about the IFComp is that, if we’re going to have 50+ games in it with a really high average level of quality and a really diverse and deep gamut of approaches, the single ranked list starts to look kind of inadequate for representing and encouraging that. So while I do like the approach where everyone enters the Comp in the same footing – no categories or separations – I think that a move to a format with multiple awards given by different groups and through different methods might be positive, though I recognise that it is organisationally more taxing than the present format.
XYZZY helps with this somewhat. I think XYZZY is much more prestigious than IFComp. I plan on nominating Cape for a Best Story XYZZY. But there are several parser-specific categories in XYZZY; it would be nice to have some web-game-specific categories. Although web-based games have dominated best writing and best story for the last few years.
This seems like something McT could address in an update. I’m pretty sure you can include captions for pictures in Inform, and he could give all the maps different captions to state in text where the new rooms are appearing. It doesn’t seem like it would detract from the story to me, because whether you see a new room on a map or read about a new room in a list, you’re still suddenly learning that a new room appeared.
I should point out Map in particular does accommodate. I first played the online version without graphics, and the map gives a written description of the new areas that makes it possible to use.
I don’t really think any XYZZY categories are parser-specific. The closest to that would be Best Puzzles and Best Individual Puzzles, though that’s really more a technological thing (there’s no choice system in common use that offers a robust world model that people can use to easily build puzzly games, and as a result puzzles are rare in choice IF).
And yeah, though what I envision for the Comp is less awards for specific things and more awards that have different voting bodies. A general public vote, an award given by alumni of past comps, jury panels, and so on. We’ve seen how the general vote and Ms Congeniality reward different games; maybe we can put that to work using the comp to recognise a broader variety of games. Moving away from having a single “winner” would probably also be invaluable when we’re evaluating 50+ games.
You can get graphics with Vorple, can’t you? And you can definitely do it with the new Quixe. I had to figure that out for a game that I was working on last month.
Regarding experimental games, as long as the comp remains a publicly-voted contest I don’t see experimental games doing well relative to crowd-pleasers. IIRC games like Shade placed extremely poorly in the comp back in the day. But I don’t necessarily see a problem with that; experimental games can be rewarded at other venues (such as XYZZY). The same is true for games with strong ideological themes (e.g. porpentine and Kaleidofish’s works).
Is there anything authors could do to make the html in Twine usable by screen readers? Bold the text? Capitalise it? Enclose it in square brackets or something similar?
I haven’t actually looked into it but based on experience with similar systems I’m almost certain that the main problem with Twine and screen readers is that passages aren’t separate HTML pages but the same page that just changes its own text. The page would have to notify the screen reader each time when there’s new content. It’s not something authors could fix.
Then there’s the problem with links that change only their own text which is more of a design problem than a technical one (should it trigger a re-read of the entire passage or just the changed text, or something else?)
Screen readers should pick up DOM additions and changes. I suspect the issue is related to the fact that Twine uses Tiddlywiki underneath. I’d guess that it’s too messy and complicated for screen readers to make sense of, rather than raw DOM manipulations.
If I’m right other choice based systems like Undum should be more accessible.
How to appropriately announce changes to links is another issue, but a secondary issue compared to nothing but the title being announced.
I use a screen reader as well, JAWS, and I share some of your frustration. This year’s comp seemed particularly rough on screen readers, maybe partly because of the volume of entries. Some were completely inaccessible and some were difficult to work out how to play. I’d like to see entries with images not only mention that images are involved, but also whether or not they are essential to playing the game and if I should be able to play the game with a screen reader. I gave up on Map because I wandered around a lot wondering if I needed to see the map. Any sort of fancy formatting should be mentioned up front, really.
I don’t seem to have a problem with most Twine games, though, including Birdland, but the trend is definitely toward reduced accessibility. Do you use JAWS? I find Firefox is the best browser to play the games. I think most choice-based games are accessible, including ChoiceScript, Squiffy, Undum, and Inkle games.