Is it an issue related to Adaptive Cards?
No.
What is the PWD impact?
Screen reader users hear the entire bot response again when focus moves to a message action such as Copy, Like, or Dislike. This makes it difficult to identify the focused control and creates confusing, repetitive narration for long responses.
What browsers and screen readers do this issue affect?
Windows: Edge with Windows Narrator
Are there any code-based customization done to Web Chat?
Yes, however, this also repros on the Web Chat-native Copy action without a custom action renderer. The host adds message metadata (AllowCopy and LikeAction/DislikeAction potential actions), while Web Chat renders the toolbar, buttons, and their accessible names.
What version of Web Chat are you using?
Development build: 4.18.1-main.20260204.e78ed2d
Which area does this issue affect?
ARIA roles; Others or unrelated
What is the public URL for the website?
No public URL is available.
How to reproduce the issue?
- Render
BasicWebChat under FluentThemeProvider.
- Enable the Web Chat-native Copy action for a bot response, or provide
LikeAction and DislikeAction entries in potentialAction.
- Send or display a bot response containing multiple sentences.
- Start Windows Narrator.
- Press TAB until focus moves to Copy, Like, or Dislike beneath the response.
- Observe the accessible name announced for the focused button.
What do you expect?
Narrator should announce only the concise name and state of the focused action, such as "Copy button", "Like button", or "Dislike button".
What actually happened?
Narrator announces the entire bot response together with the focused action. The same behavior occurs on the Web Chat-native Copy button, indicating that the action-toolbar button is deriving its accessible name from the surrounding message content.
Do you have any screenshots or recordings to repro the issue?
No public recording is currently available.
Did you find any DOM elements that might have caused the issue?
The issue appears to originate in Web Chat's message action-toolbar rendering. The action buttons are nested within the bot response article, and their computed accessible names include the response text.
MAS reference
MAS 1.3.1 - Info and Relationships
WCAG reference
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships
WAI-ARIA reference
https://www.w3.org/TR/accname-1.2/
Adaptive Card JSON
Additional context
The host application does not render these buttons or assign their accessible names. It only supplies action metadata. A host-side aria-label on the surrounding Web Chat article did not resolve the button announcement because it does not control accessible-name computation inside the Web Chat toolbar.
Is it an issue related to Adaptive Cards?
No.
What is the PWD impact?
Screen reader users hear the entire bot response again when focus moves to a message action such as Copy, Like, or Dislike. This makes it difficult to identify the focused control and creates confusing, repetitive narration for long responses.
What browsers and screen readers do this issue affect?
Windows: Edge with Windows Narrator
Are there any code-based customization done to Web Chat?
Yes, however, this also repros on the Web Chat-native Copy action without a custom action renderer. The host adds message metadata (
AllowCopyandLikeAction/DislikeActionpotential actions), while Web Chat renders the toolbar, buttons, and their accessible names.What version of Web Chat are you using?
Development build:
4.18.1-main.20260204.e78ed2dWhich area does this issue affect?
ARIA roles; Others or unrelated
What is the public URL for the website?
No public URL is available.
How to reproduce the issue?
BasicWebChatunderFluentThemeProvider.LikeActionandDislikeActionentries inpotentialAction.What do you expect?
Narrator should announce only the concise name and state of the focused action, such as "Copy button", "Like button", or "Dislike button".
What actually happened?
Narrator announces the entire bot response together with the focused action. The same behavior occurs on the Web Chat-native Copy button, indicating that the action-toolbar button is deriving its accessible name from the surrounding message content.
Do you have any screenshots or recordings to repro the issue?
No public recording is currently available.
Did you find any DOM elements that might have caused the issue?
The issue appears to originate in Web Chat's message action-toolbar rendering. The action buttons are nested within the bot response article, and their computed accessible names include the response text.
MAS reference
MAS 1.3.1 - Info and Relationships
WCAG reference
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships
WAI-ARIA reference
https://www.w3.org/TR/accname-1.2/
Adaptive Card JSON
Additional context
The host application does not render these buttons or assign their accessible names. It only supplies action metadata. A host-side
aria-labelon the surrounding Web Chat article did not resolve the button announcement because it does not control accessible-name computation inside the Web Chat toolbar.