[MAS2.4.3]Focus is landing on non-interactive elements after activating the 'Show a simple' Adaptive cards button.

[priysn]

Actual Result: Focus is landing on non-interactive elements after activating the 'Show a simple' Adaptive cards button.

Expected Result: Focus should not land on non-interactive elements after activating the 'Show a simple' Adaptive cards button.

Repro Steps:

1. Open URL https://microsoft.github.io/BotFramework-WebChat/full-bundle/ in Edge browser.
2. Notice 'Upload File' and 'Send' button icons present in bottom of screen.
3. Type 'Help' in the input control at the bottom of the screen and hit enter (or click on send button). Content will upload, Navigate to any "Show a simple Adaptive cards " button by using Tab key and press Enter on it.
4. New data will appear.
5. Navigate to the new uploaded content by using Tab key.
6. Observe that focus is landing on the non-interactive element.

User Impact: If focus lands on the non-interactive elements then user will get confuse and not able to understand that what action will do.

MAS Reference: MAS 2.4.3 - Focus Order (05)

Test Environment: OS: Windows 10 OS Build: 17134.345 OS Version: 1803 Browser: Edge

**Attachment: MAS2.4.3_Focus is landing on non-interactive element.zip

[compulim]

Adaptive Cards is setting tabIndex="0" to the root container, regardless whether the card is clickable or not. Some cards do support clicking on, but the "simple card" mentioned in this issue should not be clickable.

If you visit https://adaptivecards.io/samples/, you will see the DOM tree looks like the following screenshot.

This is a bug on Adaptive Cards. Please file a bug on their repo.

[compulim]

Reopening so we can confirm from the accessibility team.

[corinagum]

Confirmed with accessibility team as external. Adaptive Cards issue can be found here.

[dclaux]

I have been looking at this today and here are my findings:

• The apparently desired behavior calls for removing the tab stop on the root card container
• That would indeed be a better for anyone that has no disability and is able read and see the card
• But removing that tab stop makes narrator not stop on the card, and thus not read it. That seems really bad to me when it comes to actual accessibility

So my conclusion:

• "Fixing" this issue would favor power users over people with disabilities who use narration
• I do not believe there is a fix; we need to keep the root card as a tab stop

I think we'll need to look into other ways to solve this if it is critical (is it?)

Thoughts and comments welcome.

[corinagum]

@dclaux That's a really good point.

@awalia13, would you have time to look at this? Please let us know if we can close the issue on the AC repo as no-op, or if you have suggestions on another way to fix.

[awalia13]

Agreed with @dclaux. hence closing this bug.

[paulcam206]

@awalia13 - you might consider reopening this issue, as we've made a fix over on the AdaptiveCards side (see microsoft/adaptivecards#4019). Narrator is indeed able to read cards correctly without a tabstop. To adopt this fix in your codebase, you'll need to make a small change to enable the desired behavior.

[ashish315]

@corinagum As we checked, the bug still repro's at our side. Still our focus lands on the non interactive card which doesn't have any functionality. Please refer the attached video "focus lands on non interactive card.zip"

Uploading focus lands on non interactive card.zip… Correct URL: https://microsoft.github.io/BotFramework-WebChat/01.getting-started/a.full-bundle/

[Amit8527510735]

HCL;#Accessibility;#HCL_BotFramework_WebChat;#A11yMAS;#WCAG2.4.3;