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

Accessibility: submit buttons, focus corrections #3533

Closed
scheyal opened this issue Oct 12, 2020 · 2 comments
Closed

Accessibility: submit buttons, focus corrections #3533

scheyal opened this issue Oct 12, 2020 · 2 comments
Assignees
Labels
area-accessibility Bot Services Required for internal Azure reporting. Do not delete. Do not change color. bug Indicates an unexpected problem or an unintended behavior. customer-replied-to Required for internal reporting. Do not delete. customer-reported Required for internal Azure reporting. Do not delete. needs-team-attention

Comments

@scheyal
Copy link

scheyal commented Oct 12, 2020

Filed for tracking. Please close if addressed/won't fix or comment accordingly.

The following accessibility issues are filed on behalf of customer/1P.

Issues reported by customer via 1P (HealthBot):

  • Forms within the chat do not contain submit buttons. (Chris: Those actions are automatic and don’t allow the user to key through the options prior to committing a response. Screen reader users have an advantage in that the software allows them to hear the options prior to committing, while keyboard-only users have one opportunity to make the correct choice for their needs. This could very well be an issue with Adaptive Cards and would require engaging with them.)
  • Focus is not advanced to the current step in read order. (Chris: This is by design, changing focus like this will interrupt the screen-reader and kill narration.)
  • If user leaves the chat, the focus is lost. Re-entry of the Chat moves focus to the top of the UI. Only the items present in the viewport from the start position of the chart are available to the screen reader. The must user arrow down to hear elements but will not be able to see the what question they’re answering. (Chris: This seems like a reasonable ask, however the existing behavior to our knowledge is complaint with WCAG 2.1).
@scheyal scheyal added bug Indicates an unexpected problem or an unintended behavior. customer-reported Required for internal Azure reporting. Do not delete. Bot Services Required for internal Azure reporting. Do not delete. Do not change color. labels Oct 12, 2020
@corinagum
Copy link
Contributor

corinagum commented Oct 12, 2020

  • Forms within the chat do not contain submit buttons.:
    • I don't have quite enough context, so I'll defer to what Chris says and recommend potentially engaging with Adaptive Cards. @scheyal is it possible to get more details/screencaps? (I don't think I'm a part of this thread) Thanks Eyal.
    • Engage with Adaptive Cards
  • Focus is not advanced to the current step in read order:
    • By default Web Chat does not focus on message activities, only interactable items (scan mode allows traversing the text in combo with the DOM, but that is not applicable here). Making each activity focusable would need to be enabled by the developer, and there would still be no jump of focus to that element.
      • Maintaining focus on the item that was pressed is a design decision. To a user without sight, changing to the latest activity’s options is an arbitrary focus change that doesn’t maintain DOM order within the app. For example, if multiple activities come in from the bot in quick succession, each with a focusable element (such as a button or combobox), focus would jump down then jump again, skipping interactable UI.
      • In addition, using visual UI as an example, pressing a button does not inherently change focus; pressing a button will populate an action, but focus stays on that button until the user clicks or tabs away. An exception to this rule would be navigational buttons that reload the page.
    • By design/won't fix
  • If user leaves the chat, the focus is lost.:
    • This came up in a separate a11y discussion recently. Our audit doesn't include testing Web Chat as a widget (as opposed to the only app on the page), so questions similar to this are not tested/addressed. Does this fall under Web Chat's accessibility, or the accessibility of the app using WC as a widget?
    • Is this a scenario we should be adding to our a11y audit?
    • I spoke with our accessibility team and will report back here

For now, the only action item (for Web Chat team) is for the last bullet, which I will bring up at our next team meeting.

@corinagum
Copy link
Contributor

After discussing with the a11y team, returning focus to the same place in the widget is a responsibility of Web Chat as a P1 feature. Filed at #3550

Web Chat as a widget should be added as a scenario to a11y audits.

Closing this issue. Please continue widget focus memory conversation linked above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-accessibility Bot Services Required for internal Azure reporting. Do not delete. Do not change color. bug Indicates an unexpected problem or an unintended behavior. customer-replied-to Required for internal reporting. Do not delete. customer-reported Required for internal Azure reporting. Do not delete. needs-team-attention
Projects
None yet
Development

No branches or pull requests

2 participants