Accessibility updates flagged by IFD

[rebeccaalpert]

• Toggle menu button label should be more descriptive
  • While calling this button “toggle menu” is sufficient to pass accessibility checks, it would be helpful to let users know what kind of menu it is (especially since it’s not a navigation).
  • Potential solution: Something like “Chat history menu toggle” would be more descriptive.
• Toggle menu button should announce expanded/collapsed state (our examples already do this, so I am skipping this -- IFD will need to add on their side)
  • When in focus, the button should state whether its associate panel is open or closed.
  • Potential solution: Apply an aria-expanded attribute to the button.
  • Chat history menu items should be right after button in focus order
• After opening the chat history menu with keyboard, focus continues down the main section of the page, only entering the menu after the “Theme switch” toggle is focused. (our examples have a focus trap, so I am skipping this -- IFD will need to adjust on their side)
  • Potential solution: If possible, I think the close button within the chat history menu should be the next item to receive focus after the menu button is used to open the menu.
• “New chat” button should not disrupt expected focus order. Browser: Safari (our main example already sends focus correctly if you turn on Safari keyboard tab or just hold down the option key while tabbing - Safari disables some keyboard navigation by default. Skipping this.)
  • It seems that the only function that this button serves when there are no chats in history is closing the chat history menu. When using a keyboard, it also sends keyboard focus all the way back to the beginning of the page.
  • Potential solution: Honestly, I think this button should not appear at all if there’s no current chat in the main window. If it must, it should just close the menu and place focus back on the menu toggle button—or possible right to the chat text input. Either would be more logical than sending focus all the way to the beginning of the page.
• Close button activation should not disrupt expected focus order. Browser: Safari only (our main example already sends focus correctly if you turn on Safari keyboard tab or just hold down the option key while tabbing. Skipping this.)
  • Upon clicking this close button, keyboard focus returns all the way to the top of the page, making screen reader users start over.
  • Potential solution: Place focus back on the menu toggle button when the panel closes, so users will keep their place.
• Search box label should match/include visible text content
  • The visible text for this search box is “Search previous conversations,” and the aria-label value is “Filter menu items.” A form label should include the visible text (and can expand upon it, if desired, though that’s probably not necessary here).
  • Potential solution: Change the aria-label value to “Search previous conversations.”
• Updated filter results should be announced to assistive tech
  • When the filter results change as a result of user input, the page should announce to assistive tech that the results have been updated, like announcing “no results found” in the above screenshots.
  • Potential solution: Add an aria-live region to the page where updates are announced. This could be the most complicated issue/solution here, so I understand if it’s put on the back-burner.
• Rethink the menu roles in this section
  • I’m not sure the individual sections in this menu should also have menu roles. Something to think about.
  • For example, the <ul> list of previous chats has a menu role. Because of this, screen readers may announce “Press escape to close the menu.” But pressing escape does nothing. It doesn’t collapse the <ul>, nor does it close the menu panel.
  • Potential solution: I’d want to discuss this before making any firm recommendations. Maybe the <ul> just keeps its default role, as do the <button> elements within its <li> elements!
• “Back to bottom” button sometimes appears when there is no need for it
  • Occasionally, I’ve seen the “Back to bottom” button appear, even when I have yet to enter anything in the chat window, so clicking it does nothing. I’d have to examine how to reliably reproduce this to offer a potential solution.
• “Back to bottom” button is sometimes unreachable via keyboard
  • As the user tabs through the page, the “Back to bottom” button is often visible, but never reachable. By the time the user could tab to it, it’s gone. Might be worth discussing.
• “Back to bottom” button label should match visible text
  • The visible text for this button is “Back to bottom.” However the aria-label is “Jump bottom button.”
  • Potential solution: Use “Back to bottom” as the button’s aria-label value.
• “Back to top” button label should match visible text
  • The visible text for this button is “Back to top.” However the aria-label is “Jump top button.”
  • Potential solution: Use “Back to top” as the button’s aria-label value.

Worth pinging Anuj once these are fixed so he knows he can just upgrade.

[rebeccaalpert]

Breaking jump buttons into #614.