Accordion pattern: blocking problem with the recommendation to use Up and Down arrows for keybord interactions

[juliemoynatPro]

Hi,

I'm testing an accordion where the optional recommendations to use Up Arrow, Down Arrow, Home and End as keyboard interactions have been followed.

But, I'm facing a blocking problem: while Up and Down arrows move my focus from an accordion header to another, I can't scroll the page anymore to read the content of the accordion I've just opened.

This is unusable.

Is it possible to remove these recommendations? Or adding a modifier key (I've read issue #357 where I learnt that was the case initially)?

Note: Home and End keys also prevent to go to the top or bottom of the webpage but it's more easy to leave the accordion group before doing it again so I'm not sure it's a problem.

[mcking65]

This is partly why those keyboard commands are optional. That was a compromise solution. Clearly, it is not ideal.

To scroll the panel, can you tab off the header and then press down? Alternatively, does pagedown scroll in your browser?

#357 is about moving focus from elements inside the accordion panel to its header, not about scrolling. That's a really old issue; not sure why it is still open.

Adding this to the next meeting agenda.

[juliemoynatPro]

This is partly why those keyboard commands are optional.

But there is no warning in the page to explain that whereas it's a huge problem. I really think that those keyboard commands should never be implemented.

To scroll the panel, can you tab off the header and then press down?

No, I need to tab off the whole accordions because tab is also for navigating through the headers.

Alternatively, does pagedown scroll in your browser?

Yes, it scrolls but too much: I can't go where I want so I can't read the accordions content.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Accordion keyboard issues.

The full IRC log of that discussion

<jugglinmike> Topic: Accordion keyboard issues
<jugglinmike> Matt_King: There are a mix of older and newer issues
<jugglinmike> Matt_King: I thought it would be useful to look at a couple of these together
<jugglinmike> Matt_King: We'll start with issue #3406 and reference our discussion from #357 if we find that it is relevant
<jugglinmike> github: https://github.com//issues/3406
<jugglinmike> Matt_King: The person who raised the issue is representing that a conflict between the scrolling with arrow keys and moving between accordion header is a blocking problem
<jugglinmike> Matt_King: We have a lot of composite widgets that use the up and down arrow keys (e.g. menus, vertical tabs, list boxes, grids, etc.)
<jugglinmike> Matt_King: The up and down arrow keys perform the function of navigating within the composite widget rather than scrolling the page. Generally, the way to handle that is to remove the focus from the widget
<jugglinmike> Matt_King: But the accordion isn't a composite widget. It's a collection of independent headings that aren't truly connected to one another
<jugglinmike> Matt_King: I guess that because of that, this accordion thing has always been kind of contrived
<jugglinmike> Matt_King: But there are still things within Open-UI about making accordions. There seem to be some general conventions that say that accordion is an entity out there in the world and that people want some way to design and build them
<jugglinmike> Matt_King: So in my head as I review this issue, I wonder if there should be any guidance at all regarding moving from one accordion to another
<jugglinmike> Matt_King: I think if we answer these questions, we will also address the related issue #357
<jugglinmike> jongund_: Our example doesn't use those keys
<jugglinmike> Matt_King: That's right. They are optional. There was a time where we implemented support for them, but we simplified it a lot. I believe Sarah removed them
<jugglinmike> jongund_: There are so many other things that people need to think about. If we don't implement them... Are there ones out there in the world that actually use these keys?
<jugglinmike> jongund_: There is no role that says "I am an accordion". If I don't know that I'm in an accordion, I'm never going to use those keys, anyway! I would just take them out
<jugglinmike> jongund_: This seems like an easy one to dispense with because in my opinion, we have higher-priority things to be working on
<jugglinmike> arigilmore: I think my company has a different accordion implementation that may need to be updated according to these guidelines
<jugglinmike> arigilmore: But we haven't come across these issues before
<jugglinmike> Matt_King: The expand/collapse functionality of the accordion is sort of intended to help people get from one header to the next. If you want to move quickly between them with the keyboard, you just collapse the header, and the next one is usually just one or two tab stops away
<jugglinmike> Matt_King: Way, way back (and I mean way back before we re-did the accordion pattern), the original accordion pattern that was never published in APG (circa 2014), there was an idea that the accordion headers were tabs. We scrapped that whole approach because there was no way to do the tab panel (or the "accordion pattern).
<jugglinmike> Matt_King: This might just be a legacy of that original design
<jugglinmike> Matt_King: So jongund_'s recommendation is to remove these keys
<jugglinmike> Matt_King: The issue suggests assigning a different key, but that would still have the discoverability problem that jongund_ mentioned
<jugglinmike> Matt_King: Is there any objection to removing the keys as jongund_ has recommended?
<jugglinmike> Matt_King: I'm not hearing any objections
<jugglinmike> Matt_King: Adam_Page we discussed accordions in open-ui at TPAC. Is there anything related to this there?
<jugglinmike> Adam_Page: I don't think so, but I may double-check
<jugglinmike> Matt_King: It seems like it wouldn't be particularly disruptive if we eliminated the suggestion.
<jugglinmike> jongund_: The headers are there for navigation, so if you're using a screen reader, you can just use the "h" key to navigate to the next heading
<jugglinmike> Matt_King: Right. (It's still sort of stunning to me that browsers don't have built-in methodologies for things like that.)
<jugglinmike> Matt_King: I'm looking at issue #357, now. That was about getting from inside the panel to the header.
<jugglinmike> Matt_King: We don't have a key for collapsing the panel from inside the panel
<jugglinmike> Matt_King: Going back to jongund_'s original point: it's not really a composite. It's more like a disclosure.
<jugglinmike> Matt_King: I think the answer here is the same. We removed it because there wasn't any real way of making it clear to people that that key is available. It's not a common thing; it's just something that was sort of made up to solve a problem. In practice, though, it doesn't actually solve the problem because there is no precedent (e.g. in native desktop implementations)
<jugglinmike> jongund_: I think it would be the same issue for the disclosure button. If you just had a disclosure button, you had some keyboard command to take you to that button
<jugglinmike> Matt_King: I guess it's a little bit related to popover in a sense, but none of the popovers push stuff down. They always overlay
<jugglinmike> Adam_Page: Exactly. Popovers are overlay by definition, as far as I'm concerned
<jugglinmike> Matt_King: Right, so in that case, when you have overlay, that's a visual clue that, "hey, I might be able to Escape out of this"
<jugglinmike> Matt_King: A lot of time when you have expanded or collapsed content, once you enter expanded content, you don't even realize that it's collapse-able
<jugglinmike> Matt_King: Issue #3406 can't be closed without a patch because it will actually require us to remove that text from the pattern
<jugglinmike> Matt_King: I will draft a pull request for that
<jugglinmike> Matt_King: I've assigned myself to this issue