Description/Voicing design pattern for Accordion Box

[terracoda]

I am reviewing the Interactive Description and Voicing designs for RaP's accordion box to help me with this description design pattern.

Interactive Description Design for RaP's My Challenge accordion box:

Voicing Design for RaP's My Challenge accordion box:

[terracoda]

More context and details coming soon.

[terracoda]

I have made these suggestions in design behaviour. The behavior and design for Accordion Box for both Interactive Description and Voicing are outlined in the table headers in #131 (comment)

For Trig Tour's Interactive Description this means:

• Accessible names are:

  • Values
  • Cosine Theta versus Theta (suggesting adding "Graph" in separate issue)

• No Help text for Interactive Description.

For Trig Tour's Voicing this means:

• Voicing Name Responses are:

  • Values (same as interactive description)
  • Cosine Theta versus Theta (likely without "Graph", but waiting to see)

• Voicing Hint Responses on focus when accordion is collapsed:

  • Expand to show angle measure, coordinates, and trig value.
  • Expand to explore graph of function versus angle.

[terracoda]

@jessegreenberg , I think these patterns for Interactive Description and Voicing can be part of common code.

[jessegreenberg]

After reviewing #131 (comment) it looks like the change request is

• AccordionBoxes should have a voicing hint response but not have help text. The voicing hint response is only available when the AccordionBox is collapsed.

Is that summary correct and is that the desired pattern for all AccordionBoxes? Can you describe the reason for removing the help text? I ask because we recently added a feature to common code to make the default voicingHintResponse match the value of helpText so I think it would be great (more simple and more scalable) if we can keep trying that.

[terracoda]

@jessegreenberg asked

Is that summary correct and is that the desired pattern for all AccordionBoxes? Can you describe the reason for removing the help text? I ask because we recently added a feature to common code to make the default voicingHintResponse match the value of helpText so I think it would be great (more simple and more scalable) if we can keep trying that.

1. The summary is correct.
2. Reasoning: For Interactive Description, the semantics of the PDOM explicitly communicate the expanded and collapsed states of the accordion automatically on focus. The role of button is also communicated automatically. Help text is not explicitly needed to guide the interaction when getting TTS through the Interactive Description feature. Implicit scaffolding is always preferred to explicit instructions in the design of sims and sim features.
3. The default voicingHintRespponse should match the value of the helpText. This is awesome! However, helpText for interactive controls is optional and only designed/provided when additional guidance or additional context is needed.

Given point 3, if helpText is not needed for an interactive control in the Interactive Description feature, there should still be an option to provide a voicingHintRespone for that same control in the Voicing feature. This option would also allow for a voicingHintRespone to be different from the helpText - ideally option is to be avoided, but nice to have the flexibility.

[jessegreenberg]

OK thanks @terracoda - during a meeting today we also talked about the following options to support this behavior:

      // One option for each state -
      voicingHintResponseExpanded: '',
      voicingHintResponseCollapsed: 'My Voicing Hint Response Collapsed',
      
      // Since AccordionBox should generally NOT have helpText, these are usually empty and have no default fall-back behavior.
      accessibleHelpTextExpanded: '',
      accessibleHelpTextCollapsed: ''

[jessegreenberg]

OK, the requested changes have been made to AccordionBox. @terracoda can you please review the behavior?