Document the design process for adding alternative input to a simulation

[jessegreenberg]

It would be helpful to create a high level checklist that describes how to add alt input to a simulation, and what to think about.

[terracoda]

I spoke with designers, we talked about several things, but we did not determine a high-level checklist. I'll have to draft one and get feedback.

[terracoda]

Not sure this is what we want, but here's a start:

• Start thinking about ALT Input as early as possible in the design process.
• Keep PDOM order in mind throughout design process.
• Group Tab order under Play Area and Control and prioritize order based on pedagogical goals/needs and efficiency.
• Think about hot keys that could increase efficiency.
• Create Keyboard Shortcuts Dialogs for each screen as last part of design process.

[terracoda]

Actually there are 3 Design Tasks in the Alternative Input design doc template. Those seem to be a good checklist, so just adding the first one about starting early.

1. Start thinking about Alternative Input as early as possible in the design process.
2. Organize Interactions within Play Area and Control Area.
3. Create a Keyboard Shortcuts Dialog.
4. Accessible Text for Keyboard Shortcuts Dialog (not required for Alternative Input alone; required for Interactive Description and Voicing features).

[terracoda]

Updated Checklist:

1. Start thinking about Alternative Input as early as possible in the design process, and include the team member with Alternative Input design expertise on a regular basis as interactions are being considered. This can influence interaction choices.
2. Organize interactions in the order of pedagogical importance within the Play Area and Control Area. This can influence layout decisions.
3. Nearing interviews, create a Keyboard Shortcuts Dialog. Common code interactions have generic associated keyboard instructions. Adjust the generic headings and verbs if pedagogically necessary. For example, you might want to use "move" instead of "adjust", for a slider-type interaction. Keep instructions simple with one action per key press.
4. Accessible text for Keyboard Shortcuts Dialog is needed in addition to the visual display when features include Interactive Description or Voicing. There's a standard way to write the accessible text.

[terracoda]

Amanda suggested the following for the Inclusive Features/Alternative Input section of the Sim Checklist:

• Alternative Input (Started: ) (Completed: )
  • Organize interactions in the order of pedagogical importance within the Play Area and Control Area
  • Create screen-specific Keyboard Shortcuts Dialogs.
    • Ensure all sim-specific actions come before “Basic Actions”.
    • Adjust the dialogs default headings and instructions to suit the sim where needed.
    • Write accessible text when Interactive Description or Voicing are present

We'll discuss the adjustments to the Design section of the same check list at the next design meeting.

[terracoda]

Designers recently updated the main sim checklist. I'll check there if anything about Alt Input is included on that check list.

[terracoda]

Designers decided that they don't even need to mention Alternative Input on the Sim checklist or the Sim Republication check list because it is required.

And we now have auto-creation of Keyboard Help dialogs, so that is not longer a top concern.

I think what the team is having some trouble with at the moment is much more sim specific:

• how to order interactions in the PDOM especially when the main interaction starts in an "empty" state
• ways to word help text to be inviting and to add some perspective to interaction with the context of the sim
• when/how to use accessibleRoleDescription - a check is in the Core Description Check list for this
• what are object responses versus context responses and how the responses be capitalized. This an issue for custom interactions only. This is more about description than Alt Input.

I think we need more guidance around Alt Input and Description design, especially for custom interactions.

I am not sure we need a design guide specifically for Alternative Input.

[terracoda]

I checked and updated the Core Description Review checklist.

I added some examples and exceptions for help text and capitalization, nothing too specific to Alternative Input.

[terracoda]

I would like to bring this back to the priortization meeting to understand the deliverable that is needed to close this issue.