fix(JumpButton): Back to bottom a11y

[rebeccaalpert]

Users should be able to tab to both buttons. Both should perform well in auto-scroll and normal usage.

Assisted-by: Cursor

Fixes #861 and #825.

[patternfly-build]

Preview: https://chatbot-pr-chatbot-865.surge.sh

A11y report: https://chatbot-pr-chatbot-865-a11y.surge.sh

[thatblindgeye]

Some general comments/issues:

• When clicking the "to bottom" button, focus remains at the top of the message container, so continuing to Tab you're brought back to the first focusable element in the container at the top, rather than to the first focusable element in the footer area. Ideally we probably want to shift focus to the first or last message container depending on the button that is clicked.
  • Additionally, the "to bottom" button is no longer visible after triggering it in this way
• Even when one of the buttons isn't visible, focus still goes to it, triggering the tooltip on an invisible button. You can also activate the button while it's invisible like this
• We end up with the inverse issue for the "to top" button: if you're at the bottom of the message container but want to go back to the top, you're unable to reach the "to top" button until you shift+tab though everything else in the container, and by the time you'd reach the button it would no longer be visible.

From what I can tell Gemini doesn't use any scroll buttons, and ChatGPT only uses a "to bottom" button (though that can't be focus via keyboard at all). A couple others I looked at also do things one of these two ways.

It all becomes trickier if we take into account a scenario where the scroll position is in the middle, causing both scroll buttons to render, and a user is somehow able to have focus either before or after the message container without the scroll position moving (one scenario might be a voice recognition program perhaps? E.g. a user speaks to have focus placed somewhere in the footer, so the scroll position likely wouldn't shift. another scenario is a user that alternates between mouse and keyboard - they scroll via mouse to the middle, click the input, decide they want to scroll to top/bottom via keyboard).

Potentially things we could do:

• Update the structure so the "to bottom" button renders before the message container, and the "to top" after the container. That would accommodate the most likely scenarios (user navigating forward and needing the "to bottom" button, user navigating backward and needing the "to top" button
• That might not resolve the "middle scroll position" scenario - a user might want either scroll button, but can only get to one depending where they're navigating from, which essentially just results in the current bug for one of the buttons not being focusable before it disappears due to Tabbing/Shift+Tabbing to the applicable position first
  • Possible solution 1: we essentially render 2 sets of each scroll button, detecting when each needs to be visible/focusable. Might cause complicated logic, considering we'd need to know which ones to render and when based on where the user previously had focus + where they would have focus based on whether they're Tabbing or Shift+Tabbing
  • Possible solution 2: we only render 1 scroll button at a time, based on whether the scroll position is closer to the top or bottom of the message container. Less ideal especially if the message container is huge, but from an accessibility standpoint might be a tidier solution than trying to handle both buttons at the same time
  • Possible solution 3: we just don't use a "to top" button, like a couple other chatbots I've tried. Likely not ideal right now for us to do.

Maybe something we can discuss/mull over in this week's sync call?