Webchat Widget Accessibility issue

[jason-walgreens]

When hidden or new content is revealed or available on the same screen because of any user interaction then focus need to move to the new content either immediately or with one additional keystroke, so that a screen reader user can relate and access the new content without any interruption. In current implementation when a user types something and because of this input a new set of options are available on the chat modal for user to select options from, focus remains in the input field (Type your message, field). Screen reader reads the appearance of the new content but does not read the location of the content and how to access them.
In order to access the options a user need to press “shift+tab” key multiple times. Which is not logical. Since user does not know the location of the newly available content, so he is also not sure on how to access them.

Expectation is, when a new content is available on the screen focus should also move to the new content so that a user can easily access them by pressing “tab” key.

WCAG references: 2.4.3

[jason-walgreens]

[proposed labels] Bot-framework, Webchat Widget, A11Y , ADA Accessibility

[tracyboehrer]

@jason-walgreens Thanks for the input. I'll add this as a feature request for future consideration.

[compulim]

If the message is interactive (card or contains buttons), the screen reader will narrate one of the followings and it should guide the end-user how to navigate to the message content.

• "Message is interactive. Press shift tab key 2 to 3 times to switch to the chat history. Then click on the message to interact."
• "One or more links in the message. Press shift tab key 2 to 3 times to switch to the chat history. Then click on the message to interact."

However, if the message is not interactive, we will not narrate these instructions as non-interactive elements (such as <h1>, <p>, or <li>) should never be focusable.

There are 2 possible failures for WCAG 2.4.3:

• F44: Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that does not preserve meaning and operability
  • The tab order which Web Chat propose, is commonly used chat UI, where the send box is below the chat history
  • As the chat history (and potential interactive content) appears above the send box, we chose SHIFT-TAB to jump to the content, as this preserves the visual sequence and common understanding of chat UI
• F85: Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent to their trigger control in the sequential navigation order
  • We believe this is for dialog/menu and does not applies to Web Chat

[SunilMiracle]

@jason-walgreens Thanks for the input. I'll add this as a feature request for future consideration.

Hi @tracyboehrer . Is there a release plan for this fix?
If Yes, could you please share the details here or a link, so that we can keep track of this fix release.

Thanks

[compulim]

In my previous reply, I mean, the issue you mentioned should not contribute to failure of WCAG 2.4.3. I have listed reasons above that why it does not contribute to failure of this success criterion.

[compulim]

As mentioned above:

• When a message with interactive content arrives, screen reader will narrate instructions on how to move the cursor to the interactive content, such as
  • "Message is interactive. Press shift tab key 2 to 3 times to switch to the chat history. Then click on the message to interact."
  • "One or more links in the message. Press shift tab key 2 to 3 times to switch to the chat history. Then click on the message to interact."
  • "Message has suggested actions. Press shift tab 2 to 3 times to select them."
• We should not move focus when interactive content arrives, we have outlined it in our ACCESSIBILITY.md, copied below
  • Don't move focus when an activity arrives (or asynchronously)
    • Screen reader reading will be interrupted when focus changes
    • Only change focus synchronous to user gesture

Closing due to inactivity.