1848848 - Add focus handling for "show more" card component

Status: NEW

(Firefox :: Shopping, defect, P3)

Description

[Amy Churchwell [:amy]]

There was some excellent accessibility feedback for bug 1842248 here: https://phabricator.services.mozilla.com/D184874#6140327 that this bug is to address.

It's expected that after the user activates Show more with keyboard, the keyboard focus is moved to the top of the new content so a screen reader user would not miss this newly added content. You could add tabindex="-1" to the last visible by default element (it would not be added into the standard focus order but JS would be able to land the focus on it) and, when there is more text added under that last visible content, use the .focus() method to programmatically set focus to that tabindexed element. Otherwise, users of assistive technology would miss that important new information that is added by their request.

Comment 1

[Anna Yeddi [:ayeddi]]

Thank you for working on it, Amy!

To clarify the expected behavior for after this bug (what is not yet working is marked inline):

1. Keyboard alone:
   1.1. User can Tab to the Show more button and the button has a visible outline when focused with a keyboard
   1.2. User can press Enter or Space to activate the Show more - the button's visual label changes to Show less
   1.3. [To be fixed] After the new content is shown and the button is changed to Show less, the programmatic focus is moved to the last visible highlight (this element could have tabindex="-1" so it won't be added to the focus order but would be focusable with .focus() JS method).
   1.4. [To be fixed] User can press Tab to move the focus to Show less button
   1.5. If the user presses Enter or Space on the Show less button, some content is hidden, the button's label is changed to Show more, and the focus stays on that button (and the focus outline is still visible)

2. Screen reader (examples of key shortcuts would be provided for NVDA on Windows):
   2.1. User can press Down arrow from anywhere (i.e. from the X Close button on the sidebar) and get to hear Snippets from recent reviews and its content
   2.2. After pressing Down arrow a couple of times, the user hears the last visible (on-screen) text highlight snippet being announced
   2.3. [To be fixed] User presses Down arrow once again and they hear Show more, button (aka they do not hear any text that is not visible on the screen)
   2.4. If user presses Enter or Space while on the Show more button, the button's visual label changes to Show less
   2.5. [To be fixed] After the new content is shown and the button is changed to Show less, the focus is moved to the last visible highlight and the screen reader user hears the announcement of that highlight.
   2.6. A user presses Down arrow and hears the next highlight being announced (this highlight was previously hidden)
   2.7. A user can press Down arrow a few more times to hear the rest of the visible highlights
   2.8. From the last highlight, the user presses Down arrow once again and they hear Show less, button
   2.9. If the user presses Enter or Space on the Show less button, the button's label is changed to Show more, and the focus stays on that button - the user hears Show more, button
   2.10. [To be fixed] If the user presses Up arrow from Show more button, they would hear the last visible highlight (the last on the screen, not the one that is not visible)

LMK if you have any questions

Comment 2

[Anna Yeddi [:ayeddi]]

Hi Amy, AFAIK, this bug is the one that is supposed to address the off-screen highlights being programmatically hidden as well, correct?

It's been very noticeable while trying to use hover with NVDA and while trying to read all and navigate the sidebar in the browse mode (with Down/Up arrows) - a user would have to listed or arrow through all highlights, basically removing the bonus of having the Show more button.

Comment 3

[Anna Yeddi [:ayeddi]]

Nominating this bug to the fast follow list (bug 1838699)

Comment 4

[kpatenio]

Sharing some of my own observations for folks wanting to work on this:

• Currently, we only display the show more button if there are at least 2 highlight categories. Otherwise, if there's only one, we render the basic card
• Plus, we don't set any attribute indicating any clipped snippets (ex. hidden, aria-hidden, etc.), so the screen reader is still capable of reading them if not visible on the card.
• In the case of the show more card, it's not always guaranteed that all snippets of the first highlight category will be visible (example), since we set a max height before clipping content.

If we really care about reading what's 100% visible before the "Show more" footer, then we can't rely on just reading the first highlight. One approach I thought of is using an IntersectionObserver to detect which highlights are visible, which would help us:

• know which snippet to set focus on after pressing "Show More"
• know which snippets to set as hidden/not visible

We could potentially set the observer in highlights.mjs to easily reach review-highlights-list via litElement's this.renderRoot. Another thing to consider is updating each snippet's visibility state whenever we switch between "Show More" and "Show Less".