- Recommendations - Recommendations for parser-based interpreter / system designers - A meta-suggestion: Let creation tools be aware of minimum accessibility needs and emit warnings or errors when there are are no a11y affordances when compiling or otherwise automatically analyzing the game code. - Support display of alt text! - APX patterns: Second Channel - In particular, current systems seem to be very weak with alt-text for sound support? - This includes systems that lack the technical ability to play sound; they’re incapable of showing meaningful alt-text if they can’t play it, let alone if the player can’t hear it - List exit options - APX patterns: Distinguish This From That; Total Recall - Maybe more generally: List contextually available stuff. Obvious exits/actions/objects nearby. - Make display of this stuff togglable, but default-on? (So that cranky traditionalists can forge ahead without it, ha ha…) - Offer a guide of common commands - APX patterns: Total Recall - One player with aphasia had trouble remembering commands due to disability, but you can easily make the argument that it’s a good idea anyway, and would help all players. - Offer up the recent work of Ryan Veeder (e.g. https://rcveeder.net/garden/) as an example here? Putting common commands right on the screen and permanently, even if only in a non-interactive frame. - Display room dscription, inventory, et cetera in separate panes - APX patterns: Personal Interface; Distinguish This From That; Total Recall; Leave It There - Ideally, allow players to adjust the size and position of these panes independently of one another, and make this a permanent preference. - Look to Andrew Plotkin’s Seltani as an example (even if that’s not parser-based)? - Other examples from parser-land? (Some of Emily Short’s more involved Glulx UIs?) - Recommendations for IF authors (parser or hypertext) - Avoid puzzles or other interactive elements that depend upon the player having knowledge or experience only available to an able-bodied person. - The example of the “6/9 button” from Zarf’s game. - This is the cousin of one of Graham Nelson’s “Player Bill of Rights” peeves from the 90s, regarding assumed cultural knowledge of the player. (The Zork II baseball-diamond puzzle.) - Use alt text! - APX patterns: Second channel - Always have alt text for all multimedia. - Furthermore, consider implementing “alt text” for things that aren’t strictly based on multimedia files, like maps drawn with text characters. - Offer prominent volume/mute controls. - APX patterns: Clear channel; Leave It There - Make it clear whether or not a given game even *has* sounds. Multiple testers unsure if one or both games were supposed to make noise. - Allow a screen reader-using player to adjust the game’s volume comfortably so that sounds or music won’t blot out their screen reader's output. - Always allow the player to set text preferences - APX patterns: Clear Text; Leave It There - Offer control over text size, font, et cetera Boon players with dyslexia as well, who might prefer easier fonts. (OpenDyslexic) - Offer a light-text-on-dark-background display option. - Offer game-specific keyboard shortcuts for moving focus between panes (and re-sending their current contents to the screen reader). - APX patterns: Same controls but different - Pair updates with sounds - APX patterns: Second channel - In general, make it more obvious when a thing changes. - Offer a small sound library of sounds assigned to particular things. (Don’t just go ding when something changes!) - Make this easy for authors to use - Consider, for example, allowing authors to tag an in-game event as “discovery” - Then when the interpreter fires this event, it plays its own standard, consistent “You made a discovery!” sound - Same with “score went up”, “you died”, maybe even “movement”, “inventory update”, and so on. - Be mindful of text that is color-coded, or otherwise has differences meant to convey meaning that screen readers might not pick up on. - APX patterns: Distinguish This From That - Implement a quick-travel mode, and other niceties that let players type less. - APX patterns: Do More With Less - Stuff IF (especially parser IF) already has good traditions for — keep it up! - APX patterns: Helping Hand, Bypass, Training Ground, Undo Redo - Hints and walkthroughs - APX patterns: Helping Hand, Bypass - Playtest thoroughly so that you cover your game with synonyms, “diegetic” hinting and redirection, and so on - Provide a separate hint system - Provide an outright walkthrough, when applicable - Offer help to IF newbies - APX patterns: Training Ground - Minimum level: links to generic how-to-play-most-games documentation - Middle level: Enabling a “tutorial voice” (perhaps automated via an extension) - Deepest level: Make a story-specific training prologue that teaches the basics, in the style of “use the left stick to move around…” introductions in every triple-A game - Make sure Undo works! (APX patterns: Undo Redo) - List content warnings when applicable - APX patterns: Moderation in All Things - If you don’t want to list warnings “on the cover”, make their availability obvious, and listable with a simple action or command. - Miscellany - (These recommendations don’t obviously map up with any APX patterns) - If displaying text in multiple panes, arrange the panes so that screen reader users can more quickly navigate to panes they will use more often. - Make sure that all significant changes to the text you are displaying cause something to get sent to screen readers. - Offer more clarity when content is loading, versus when the game is intentionally letting time pass. (Basic UX hysteresis advice applies here, i suppose.) - Recommendations for the whole IF Community - Read and understand the APX patterns, and invent new interpreters around them. - For every significant IF platform, create a standard, very simple test that will interactively test accessibility features. (Very simple “Can you see this? Can you hear this?” stuff, not even trying to be entertaining. A basic testing/diagnostic tool. * The community should perform more intense testing regarding screen effects common to parser games, including… - Make accessibility testing part of routine playtesting. - Recommendations for assistive-technology maintainers / publishers - It seems that some ATs (particularly screen readers) could stand to up their game when it comes to “non-standard” text support. - Unicode / emoji support - Some displayed very common emojis (thumbs up) but ignored others; others seemed to show nothing - Text styling (Bold, italic, et cetera) - Meta: I suspect some testers answered “English only” about what languages they saw in the sign, because they didn’t realize they could read it in different languages by entering different commands. - This really does seem to be something for AT to fix; It doesn’t seem right to ask authors to not style text or use emojis for accessibility’s sake. - But maybe authors should be mindful of known AT shortcomings, just the same. - Other thoughts - APX patterns that are less applicable to IF - Improved Precision - Slow it Down - House Rules - Play Alongside - Save Early Save Often - I saw notes about “focus” issues often among screen-reader users (including those on our own committee) and I’m not well versed enough by myself to turn them into recommendations? - We should not make accessibility recommendations based on feedback that was clearly testers being (often unwittingly!) good IF playtesters. :) e.g. asking for more verb synonyms, or more puzzle cluing. (We can mention that anyway, because it’s fun.) - We have platform data, and some yes/no answers. Do we want to *do* anything with that? - We may have relied too much on specific questions, and ended up suprised with what people had trouble with. - It may be worth a strategy of saving specific questions for future testing rounds, when you know for certain what the trouble spots are, and keeping the questions in the first round more general. - I think we can recommend exactly this with e.g. the problems that screen reader users had with the plaque puzzle in Zarf’s game.