Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[A11y] [Issue 8] Incorrect focus order within chat #3135

Closed
compulim opened this issue Apr 30, 2020 · 1 comment
Closed

[A11y] [Issue 8] Incorrect focus order within chat #3135

compulim opened this issue Apr 30, 2020 · 1 comment
Assignees
Labels
area-accessibility bug Indicates an unexpected problem or an unintended behavior. external-healthbot

Comments

@compulim
Copy link
Contributor

compulim commented Apr 30, 2020

8 Severity 2 – Incorrect focus order within chat

This is filed to #3135.

Background

After the answering the consent question and selecting “I agree” button, focus remains on that control instead of moving into the new message with new question/buttons. When pressing tab once, focus goes to “I don’t agree” button (which is still in the previous message where the question has already been answered). After answering any question, focus should move to the latest focusable button/link in the new message, in this case, it would be “United States” as shown in the screen shot below.

Investigation notes

After the "I agree" button is clicked and before new content is shown, the focus left is still left on the "I agree" button. Thus, next TAB is going to "I don't agree" instead.

We understand a lot of developers are using hero card and Adaptive Cards to prompt, thanks to their flexibility.

We also understand a lot of developers disable the send box for usability reasons.

We need to investigate multiple solutions:

  • Disable interactivity on cards, via one of the options below:
    • Disable when the user already responded on a card
    • Disable interactivity on all cards but the most recent one
  • Options to auto-focus on interactive cards as they arrive
    • Need to study if focus change is permitted under A11y rules
  • Intensive focus management
    • Remember focus history
    • When a focusable element is become non-focusable, change the focus on the last item in the focus history
    • When the focus is set on the transcript, and a new interactive card arrive, focus on the interactive card
    • Need to check if focus management should be bound to transcript, or include send box

Update of 2020-05-11 and 2020-05-17

According to WAI-ARIA Authoring Practices 1.1 Section 6.2 Discernible and Predictable Keyboard Focus

Persistence of focus: It is essential that there is always a component within the user interface that is active (document.activeElement is not null or is not the body element) and that the active element has a visual focus indicator. Authors need to manage events that effect the currently active element so focus remains visible and moves logically. For example, if the user closes a dialog or performs a destructive operation like deleting an item from a list, the active element may be hidden or removed from the DOM. If such events are not managed to set focus on the button that triggered the dialog or on the list item following the deleted item, browsers move focus to the body element, effectively causing a loss of focus within the user interface.

We should move focus when:

  • After the user click on "New messages" button, we should move the focus to the first non-disabled interactive UI after the new message button in the transcript
    • If no non-disabled interactive UI in the transcript, move the focus to the send box
  • After a new activity with interactive UI is received, check if the focus is currently on the transcript of a disabled interactive UI
    • If the focus was on a disabled UI, move the focus to the first interactive UI of the recently received activity
    • If the focus is moved asynchronously, screen reader will be interrupted. Only move focus in a synchronous manner
  • After one of the decisive buttons is clicked, we should remove tabbability on buttons which are not selected as the decision

[Bug]

@compulim compulim added bug Indicates an unexpected problem or an unintended behavior. area-accessibility customer-reported Required for internal Azure reporting. Do not delete. Bot Services Required for internal Azure reporting. Do not delete. Do not change color. customer-replied-to Required for internal reporting. Do not delete. A11yMediumImpact external-healthbot labels Apr 30, 2020
@compulim compulim self-assigned this Apr 30, 2020
@cwhitten cwhitten removed Bot Services Required for internal Azure reporting. Do not delete. Do not change color. customer-replied-to Required for internal reporting. Do not delete. customer-reported Required for internal Azure reporting. Do not delete. labels May 2, 2020
@compulim
Copy link
Contributor Author

compulim commented Jun 3, 2020

Fixed in #3150.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-accessibility bug Indicates an unexpected problem or an unintended behavior. external-healthbot
Projects
None yet
Development

No branches or pull requests

2 participants