[Accessibility-testing] Some recommendation thoughts

[Jason McIntosh]

An outline of some possible recommendations by jmac, based on survey responses...

- Recommendations for…
    - Parser-based interpreter / system designers
        - Display alt text!
            - 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
            - 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
            - 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
            - 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?)
        - The community should perform more intense testing regarding
          screen effects common to parser games, including…
            - Box quotes
            - Full-screen menus
            - Changes to the status bar
            - Emoji
                  Emoji are technically not part of the parser IF
                  tradition, but they are an increasingly prominent in
                  the definition of “text”. a wealth of good argument
                  for how not treating them as symbols equal value to
                  the rest of your software’s supported writing system
                  is a mistake and s disservice to your users.
            - Consider using NVDA, specifically, for testing?
        - Don’t discount the accessibility-through-simplicity of
          Terminal-based apps.
              Comments from one tester:
              
              Another consideration should be given to users of Braille
              displays. It is possible that screen reader output can be
              sent to a braille display, but another way to increase
              accessibility for this case is to set braille focus on
              the first line of new output.
              
              One other thing, for Mac and Linux users, terminal apps
              are the best. Sure, that won't help the ascii graphics
              and messy keyboard navigable menus, but it does make sure
              that the screen reader is in more control of what it
              says, as it always speaks new content, not old content
              while scrolling, unless that functionality is toggled
              off. A terminal experience is great for braille users as
              well.
              
              On Windows, there is the power shell, and it also seems
              to turn well with screen readers.
              
    - 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.
    - 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.)
        - Consider implementing unofficial “alt text” for things that
          aren’t strictly based on multimedia files, like maps drawn
          with text characters.
        - Use alt text!
        - Offer prominent volume/mute controls.
            - 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.
        - Offer control over text size, font, et cetera
              Boon players with dyslexia as well, who might prefer
              easier fonts. (OpenDyslexic)
        - Always offer a light-text-on-dark-background display option.
        - 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.
        - Offer game-specific keyboard shortcuts for moving focus
          between panes (and re-sending their current contents to the
          screen reader).
        - Pair updates with sounds
            - Connect this with that AbleGamers recommendation about
              providing information through multiple sensory channels!
            - In general, make it more obvious when a thing changes.
        - Be mindful of text that is color-coded, or otherwise has
          differences meant to convey meaning that screen readers might
          not pick up on.
        - Implement a quick-travel mode, and other niceties that let
          players type less.
        - Offer more clarity when content is loading, versus when the
          game is intentionally letting time pass. (Basic UX hysteresis
          advice applies here, i suppose.)
        - Make sure that all significant changes to the text you are
          displaying cause something to get sent to screen readers.
    - The whole IF Community
        - Invent new interpreters around accessible principles.
        - Work with accessibility experts to rethink text-display
          standards.
        - 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.
- Other thoughts
    - 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.