[Accessibility-testing] Building the other text-matrix axis (plus meeting reminder)

[Jason McIntosh]

Hi folks,

Thank you all for your patience. I am back from the UK and utterly exhausted, but I would still very much like to press on and host our Skype meeting tonight at 6 PM Eastern. Our main topics of discussion will be checking in on “Cloak of Access” progress (and c.f. Zarf’s mail from yesterday), as well as formalizing our list of accessibility conditions to test.

Find attached a textfile listing the testing platforms we’ve agreed on so far, expanded to cover every interpreter / browser / OS combination possible. (Let me know if I’ve forgotten any.) I count 17 such combinations for the Glulx test game, and 8 for Twine. (Sixteen for Twine, if we end up testing Harlowe and Sugarcube-based work separately.) I’ll share this in the team Dropbox too once I get access to it (have dropped furkle a note about this, just now).

Per our last meeting — the relevant notes for which I quote below — a next task involves making the other axis our testing matrix, which is various "accessibility conditions” (for lack of a better term?) including but not limited to particular assistive technologies.

Let’s make this list together, along the “80%” and function-led principles we discussed last time. I confess that I don’t really know the right way to do this, so I’m going to start by making an admittedly ignorant stab at it, just to start the conversation. Here’s what I have, off the top of my head, based on my recollection recent-past conversation:

• A screen reader is present
• A Braille display is present
• A screen magnifier is present
• No sounds are played / perceived at all 
• No visuals are displayed / perceived at all (other than text sent to any present AT devices)
• No mouse (or other two-dimensional pointing device) is present

I expect I’m missing a lot here (and may in fact be barking up the wrong tree entirely) so additions and comments are welcome.

Also, I really don’t know if we should include additional conditions for situations that are relevant to particular disabilities but not necessarily alleviated by ATs or browser settings. “Player expects to provide input relatively slowly”, for example? (I’m obviously not sure even how to phrase that usefully…)

On Jun 1, 2018, at 12:06 PM, Jason McIntosh <jmac at jmac.org> wrote:
> 
> • Other testing discussion
> 
> 	• We should start sorting out our list of ATs to test, similar to our combing out a list of interpreters. (Let’s begin this discussion on the list, presently…)
> 
> 	• Mark recommends prioritizing “must-do” combinations of AT with our other interpreter / browser / OS targets, and not worrying about technology that fewer people use, proportionately speaking. “What are your 80-percents”?
> 
> 	• Deborah further recommends prioritizing functional targets for AT over brand names and versions, when applicable. For example, testing “is using a screen magnifier” versus ticking off a bunch of leading-brand magnifier technologies.
> 
> 	• AbleGamers’ Player Panels can help us select groups of specific AT users, when it comes time. All Player Panels volunteers have filled out surveys about their own technology use. This will help us choose an initial list of potential testers to contact and ask if they can help with specific stuff we need covered.