What about a special character for meta things, like a
# WHERE LIVING ROOM
What about a special character for meta things, like a
# WHERE LIVING ROOM
Which means typing it in. This could be another problem (I was suddenly thinking if it is hard to input keys like that when using a screen reader).
Excellent point. I’d better close my eyes and start playing some parser games to find out.
One other idea is to make the meta command feel less meta…
> REMEMBER LIVING ROOM
And in the spirit of the homing signal idea…
> FORGET LIVING ROOM or just
well, depends on your familiarity with the keyboard (often I must watch meowies around looking for attention-giving mischief when at keyboard…)
Best regards from Italy,
I know people are already talking about this in another thread, but I’d also like to raise the point that accessibility doesn’t just apply to blindness or deafness. it also applies to things like:
if this is out of scope for this conversation, then fine. I just wanted to bring it up
It isn’t. I think people are bringing up things they’ve dealt with personally, but the topics you mention (and others, I’m sure) are welcome here.
EDIT: since my knowledge of the world is limited, I think it would be helpful if posters support conversations that they would like to have.
For accessibility guidance, I like Game Accessibility Guidelines, even though a fair few of these aren’t exactly pressing issues in Interactive Fiction (it’s a rare IF that has a haptic mode, for example).
I am writing a visual novel, which brings both extra options and extra requirements to the table. At the moment, the coded-in accessibility elements are:
Still trying to make work or in progress, in no particular order:
Would like to have but not sure how to make work:
This is a very impressive list of features! IIRC, you use Ren’Py. Does it support any of these features out of the box, or does it require a lot of customization on your part? I wonder which platforms/toolsets are better suited to implementing recommended accessibility features.
For instance, since Wade and I talked a little about it above: the IFTF report recommends that all “visible objects and exits” be displayed at all times by default (it can be turned off). From an Inform 7 perspective, that’s pretty complicated (EDIT: and I’m not sure screen readers would handle it well). Twine, on the other hand, is good at this kind of visualization. I’ve seen Ren’Py games do this kind of thing, too, but I don’t know how easy it is.
The base capabilities and strengths of different development systems vary so much.
Warning! Long reply alert!
Short answer: Ren’Py has quite a few features out of the box, some that are trivial to add, some that require a bit of programming (but nothing likely to daunt someone used to, say, Inform) and some that require substantial programming. However, none of the things I’ve described, as far as I know, require quite as much programming as some Ren’Py authors employ in order to make their visual novels graphically compelling (that, to my less experienced eye, is next door to magic).
To answer some of your latter points first, Ren’Py by default displays every choice, thus every exit. It’s possible to hide/reveal choices that can’t currently be taken, hide choices until some trigger is met, prioritise which choices are seen and hide the rest or do other tricks to obfuscate options. However, all of these are more complicated than the accessible choice of simply showing every option. (In theory it’s even possible to use a menu item to launch a parser or psuedo-parser, although that would be hilariously complicated to program.)
Objects are more difficult, largely because Ren’Py doesn’t assume any objects will be involved by default. These have to be programmed and described individually. If one wants those objects to be visible, one will need an inventory. (Budacanta has a “rucksack” facility for this; it’s straightforward enough to program the container. Rather more difficult is programming when items will be visible. Even more so if one would like to be able to use items manually in the inventory. The latter two elements don’t get much help from Ren’Py, although it is possible with canny use of the state-tracking). Making it visible at all times would require two separate user interface changes (one for the choice screens and another one for the rest), may not be compatible with self-voicing or screen-readers, and would cause user interface problems for sighted players in the typical mid-game inventory situation.
Ren’Py’s self-voicing will handle all visible text, although screen-readers’ ability to do likewise may vary (I’ve not figured out how to get NVDI to work with it).
Ren’Py does have some features out of the box that are helpful to accessibility. For example, the unlimited saves and auto-saves are built into the engine. It is able to do things like multiple controllers and self-voicing provided you don’t do anything that messes it up (Ren’Py allows a lot of flexibility for advanced users but one has to be careful not to lose benefits that are naturally there if one had just kept it simple).
Ren’Py has controller instructions out of the box, but not remapping, how-to instructions or tutorials. I’m still working on the remapping (at the moment, control profiles are the main delay), instructions on the first screen were as easy to program as any other choice text and the biggest issue with the tutorials was remembering to give the player the option to stop it and just play the game every so often
Translations aren’t there straight out of the box, but there is a mechanism that simplifies a lot of the necessary effort. Provided, of course, that your translators follow your instructions. Remembering to describe all backgrounds’ essential features gets easier with practise. Things like the “continue” option on the start menu and “return to before the mistake” option have to be programmed in, using Ren’Py’s ability to keep state information to help with the background book-keeping.
Rollback exists but defaults to around a dozen screens, albeit changing that requires only a number and a mental note that for an intricate, large game (think tens of thousands of screens, possible if there’s either a very long linear narrative or multiple hard-as-nails puzzles with no external game length restrictions), the novel may stop working on some slower computers due to the buffer size. (Depending on Ren’Py version, it’s possible to target computers running Windows 98, Max OSX 10.3 or - with some jiggery-pokery on the part of the player - original iPads and the Android devices of 15 years ago). There’s no tradition of writing additional files for Ren’Py games, so the “about” text file is something I created on my own initiative.
Areas where Ren’Py struggles (especially compared to parser interpreters) include text and background flexibility (every additional option has to be programmed manually; the defaults are accessible but boring enough that any player familiar with the engine will notice and wonder why the default was kept). Visual novels also tend to have lots of animation in the sprites and Ren’Py doesn’t build in any sort of “off” switch for this. (Budacanta currently gets round this by having no sprites to animate; some other Ren’Py novels program a switch in the game menu that allows animations to be turned off and/or slowed down).
Accessible status bars are very difficult to do in Ren’Py, it turns out. While lots of people appear able to do graphical GUIs, getting graphical status bars to work properly with screen readers turns out to be complex, especially if (like Budacanta) there are plot reasons for it not to be constantly available. Hence why I have the inelegant but thematic and accessible method of incorporating them into the choice menu, omitting information that definitely isn’t relevant to the player for that choice menu.
The most challenging one so far has been the music off by instrument. In fact, I only got the idea it was possible because I happened to see some code Alaric on a Ren’Py development Discord server. The original intention was to block insect and spider sounds in Alaric’s game. I asked permission to use it for music control (since my game still hasn’t got any sound), he agreed and I ended up splitting my music into different instruments to make the concept possible. Obviously, once I have sounds, those are going to be blockable by sound type too, and I can see how to extend the concept to allowing users to select types of written content they’d rather not see. I think it is worth it because it gives a way for people concerned about phobias, anxiety or stress ways to engage with the IF that aren’t limited to “play something else”. I like the idea of modestly extending what “accessible” can mean in IF.
I’ve shared my games with /r/blindgamers on Reddit and gotten good feedback, suggest sharing there if you are working on accessibility. Timed text has been the biggest issue so far, so I need to work on including ways to manually make text display. So far I’ve been using skip (like for delayed fadein on intro) and a settings option for text delay.
Twine development benefits from the general accessibility infrastructure of webdev, so I find it enticing (playing with all the different IF engines).
getting good feedback from reddit ???
Best regards from Italy,
getting good feedback from reddit ???.
Stick to the smaller communities relevant for the specific thing you want to test.
Engaging this topic for the first time, and really feeling my way through this. In addition to
I also tumbled onto Accessibility and Usability Notes for Authors , and was helpfully pointed to this thread. Trying to synthesize it all, some high level conclusions for my TADS work:
Two items felt like outliers that I’m interested in hearing how others attack:
Providing a command guide is helpful for all computer games, not just parser or IF.
If a player has anxiety, being able to see the commands before starting gives confidence that the game is completable - even if that player proceeds never to look at it again, or even note any of the specific commands.
People with memory issues like to be able to refer back to the instructions if they forget. Note that “issues” does not simply encompass people with formal memory disabilities such as dementia, but also people who need to juggle many things in working memory and occasionally drop some (be that due to having difficulties co-ordinating two hands on the keyboard or needing to cook the family dinner at the same time as playing the game because their support aide didn’t turn up for work).
Any disability involving difficulties with context changes would benefit from a command list, to avoid muscle memory trying to use a response that makes sense in a different context but not for this specific game. The source can be as proximate as a similar parser IF or as far away as the security code for a completely different building, since all it takes is for one thing in common, and lots of IF uses keyboards…
Dyslexia increases difficulties with spelling, so a command list means it’s easy to confirm whether one is trying something impossible or is making several varieties of typo.
People who have difficulty taking the perspective of others can use the command list to help them imagine how the IF author (and perhaps the IF’s characters) think about situations. A well-crafted command list can be an aid to character and setting (Zozzled is a good example of this).
And of course, even for experienced players, a command list can help with things that aren’t common in the genre. Deadline’s manual had a command list including the unusual SEARCH NEAR [something], which would be difficult to guess even for someone used to parsers. For my IFComp entry I doubt anyone would guess to SABOTAGE MACHINERY, HIDE BEHIND PANEL, or ANALYZE WEAPON without some sort of prompting.
I don’t know how good Inform 7 is at having multiple panes. I haven’t looked into it. I think some players would appreciate a pane showing verbs. Or other information. I have a “VERBS” command, but I don’t feel that it fulfills the recommendation criteria.
I think it’d be good to let the player see some of this stuff all the time if it helps (it should be optional).
It’s possible in I7 but requires extensions that haven’t yet been updated for the new version. It also requires a bit of cleverness about how you use the space, since it’s hard for the player to reposition them.
I think one often forgotten way to accessibility would be accessible language. By that I mean using as simple vocabulary as possible, avoiding unnecessary complexity in descriptions and keeping the story easy to follow while also engaging readers. Of course that’s easier said than done. Accessible language is different for everyone, and sometimes being artistic might require writing in a less easily understood way.
I’m toying with the idea of including easy to browse definitions and synonym lists in parser based games. I think it would lessen the need for disruptive googling and also help with finding options for difficult-to-type words while preserving some of the challenge for those who want it. This feature would probably require hyperlinking, though.
My wife loves when she can tap on a word on her Kobo and get the definition. The least obtrusive method is best. A tool tip / pop-up definition pulled from a locally stored file. Once a story is finished, you could parse the text and create an array of needed definitions. Then copy the definitions from a full database into your story specific, smaller definitions array.
Maybe someone has already created the tools to do this.