[Accessibility-testing] Defining our list of a11y tests

[Jason McIntosh]

Hi all,

Summary of this email: It looks like the team has already assembled a master-list of IF techs to test -- great! However, it looks like we haven't quite finalized a similar list of assistive techs or other accessibility checks. Let's begin our 2018 planning work by confirming the former, and then proceeding to codify the latter. That'll give us the two axes for our testing matrix, and we can move on from there.

The master-list of IF techs to test, posted by Furkle on June 18, seems great to me. Here it is again, with the development tools removed (per our discussion earlier this month):

• Inform
    • Quixe
    • Parchment
    • Vorple (?)
    • Zoom
    • Frotz
    • Gargoyle
• Twine
    • Sugarcane (Twine 1 Format)
    • Sugarcube (Twine 1 Format) 
    • Jonah (Twine 1 Format) 
    • Harlowe (Twine 2 Format) 
    • Sugarcube (Twine 2 Format) 
    • philome.la (?)
• ChoiceScript

I've also added ChoiceScript back to this list. It was named early in the discussion, and nobody objected, but it didn't make it into the final list -- I think that was an accident? (Furkle?)

As for accessibility techs: Folks brought up WCAG et al, which is certainly relevant, but Deborah mentioning AbleGamers' Includification document (http://includification.com) last summer really made me hit the brakes -- per my email to the list yesterday. So, here's my follow-on question there: rather than base our accessibility tests directly on a lowest-level "alphabet-soup" standard, shall we instead base it on Includification's extant work of applying these standards to video games?

AbleGamers has already put a lot of research and thought into creating checklists of ways that video games can better accomodate players with disabilities, and I wonder if we can save a lot of effort by building on that. An example of such a checklist appears near the front of Includification, specific to PC-based games. Quoting it directly (but partially):

Mobility
-- Remappable keys
-- Camera/mouse sensitivity
-- No button mashing
-- No precision needed
-- Can play with only the mouse
-- Can play with only the keyboard
-- Timing of movement/button pressing not important
-- Difficulty levels
Visual
-- No key elements of the game are identified by red and green
-- Colorblind options are present or not needed
-- Font color can be changed
-- Font size/type can be changed
-- Game presented in high contrast
-- Subtitles are easy to read
-- Subtitles are letterboxed
-- Game menus are easy to see/read/use
Hearing
-- Subtitles are present
-- Ambient noise is included
-- Identifies speaker
-- All audio cues are accompanied by visual cues
-- Game can be successfully completed without sound

Now, obviously, not all these apply to typical interactive fiction. Furthermore, because of its focus on text, IF can offer accessibility paths -- most notably for blind/VI players -- beyond those that AbleGamers recommends for highly visual video games. But I think that this might represent an excellent starting place for us, meshing in quite nicely with the survey-driven approach that Deborah recommends.

So: what would we think about creating an Includification-style master-checklist for IF, and letting this stand as the accessibility axis of the Testathon matrix? I envision adding our own list-items specific to IF and relevant AT, such as "The game can be successfully completed without displaying any images", "AT is notified of changes to on-screen text", and so on.

I suspect that this would mesh quite well with the survey-driven testing approach that we’ve been discussing so far this year?