Accessibility: [Screen Reader]: The state of the button (selected or not) is not programmatically associated with the response buttons (suggested actions)

[ericmaino]

Actual
A screen reader user does not know which response button (Yes or No) is selected. He has to come out of the response button group and read the next line of text to get that information

Expected
The state of the button should be programmatically associated using aria-checked or aria-pressed.

WCAG Violation
Name, Role Value: 4.1.2
https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

[corinagum]

These are accessibility issues of v3 of Web Chat, which has been deprecated and we no longer support unless there are security risks. For accessible Web Chat, please migrate to v4.

[compulim]

Although the button looks like a fork in an intersection (if "yes", go to step 1, if "no" go to step 3), the actual design of the button was a single action. These actions are designed to be okay to trigger/click multiple times. It's not a one-off. Thus, the button is not like a radio button or toggle button.

I think the content author should use suggested actions instead. Suggested actions is a feature designed for one-off use. That means, it will be working like a fork in an intersection, the user can only choose A or B, and not going back.

Thus, I think this is misuse of the feature, causing A11y issues.

[rp-dev]

This still repros in customer environment after migrating to v4.

I understand @compulim's response above and however moving to suggested actions would be a change that needs to be taken with health bot team which I am following up on separately.

Note that in the health bot, no text entry is allowed, when user selects Yes, there is no bubble from user showing yes, the button is simply shown as selected for the visual user. For screen readers going back to the area with yes/no should read which button is selected which it is not doing right now.

This was tested on Win10, Chrome, Jaws and customer deployed health bot.

[compulim]

Could you use suggested actions instead of Adaptive Cards? Suggested actions are designed as an one-off decision. If the design of the suggested actions are not great, can you file an enhancement issue?

We also implemented "disable Adaptive Cards button" here, https://github.com/microsoft/BotFramework-WebChat/tree/master/samples/05.custom-components/l.disable-adaptive-cards.

However, the sample can only be used to disable buttons, but not setting aria-selected because buttons in AC card are not designed as toggle button and it's outside of our scope to change the design.

[compulim]

Problem statement

Currently, we have carousel (default) and stacked. But it is not enough. People move to Hero Card because they prefer inline buttons that are one-off and disable on submit.

HealthBot also use Hero Card as the solution for QnA messages.

Work needed

Design a new "inline" layout for suggested actions

This will replace the need of Adaptive Cards for simpler question-and-answer messages.

Adaptive Cards are designed to be: dynamic and allow multiple submission. This design don't work for QnA, which is static and one-off. And it is causing issues with accessibility, because, we should not disable AC after it is submitted. But on accessibility side, it is confusing not to disable the AC buttons.

Another accessibility requirement: inline buttons can be "re-read" from the screen reader. The end-user can go back and find out what answer they chose.

Alternatives

Facebook Messenger use "persistent menu" and the UI looks like our suggested actions. The usage is different. In Facebook approach, the buttons are for "switching context", and not "answering questions and continuing the flow".

By switching context, I mean, for example, these are the buttons: "where is my order", "contact support", "previous orders". These buttons are for initiation of largely different dialogs.

Work with HealthBot team to move from Hero Card to QnA

• Understand what influenced HealthBot team to use Hero Card as QnA
• Also, understand if QnA maker is using Hero Card

[compulim]

I am building a prototype for inline suggested actions. The "inline flow" layout would looks like:

20210106.mp4

You can find the branch here.

Few notes on the prototype:

• Need to continue to implement/investigate
  • Expect 3 more days to complete the feature
  • Command emptycard is not working because it does not have a body
  • Need to study the impact on accessibility
    • Need to study the alt text "suggested actions container: empty"
      • We probably don't need this
    • Need to find out how access key will work in inline layout
      • We probably enable for the latest one, or don't need this
  • Need to highlight selected action
    • Need to remember temporarily (use markActivity) or permanently (add it to channelData of the next response and do a lookahead)
      • Seems permanent is a good choice
    • Need to implement ARIA for the selected action
  • Should we make suggested actions a type of attachment to simplify the code?
• Decisions so far
  • It seems "inline carousel" does not make much sense, so we didn't enabled it
  • We refactored <SuggestedActions> (per-activity) into <BasicSuggestedActions> (global)
    • Need to clean this one up, currently, suggestedActions prop, we should change it to activity prop to promote reuse

[corinagum]

Adding @Kaiqb to assignees for tracking purposes.

[compulim]

The original issue is fixed by PR #3710 and released as 4.12.0. I am closing this issue for now.

Will create a new feature ask for "inline suggested actions".