Heading scrolled out of view when opened in group

[geoffrich]

Describe the bug

When opening another accordion in a group, sometimes the auto-scroll moves the opened accordion heading out of view. This can cause users to miss content at the start of the accordion.

This was a hard bug to repro, but it seems to be correlated with 1) mobile screen heights and 2) long content inside the accordion. I've only been able to repro in Chrome, not Firefox. I've also seen it on iOS but had a hard time getting a minimal reproduction.

To Reproduce

Use the following HTML:

<auro-accordion-group>
<auro-accordion>
    <h2 slot="trigger">Trigger long content</h2>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
</auro-accordion>
<auro-accordion>
    <h2 slot="trigger">Trigger long content</h2>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
    <p>Content</p>
</auro-accordion>
</auro-accordion-group>
<style>
    p {
        margin-bottom: 3rem;
    }

    h2 {
        margin: 0;
        font-size: 1rem;
    }
</style>

Note: styles are important so that the accordion content has sufficient height.

1. Render this page in Chrome at screen dimensions 382x653
2. Open the first accordion
3. Scroll all the way down and open the second
4. Once the accordion finishes opening, the top of the accordion is out of view.

Expected behavior

When opened, the top of an accordion is always in view.

Screenshots

GIF of the issue:

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome 96
• Version: accordion 1.5.1

[blackfalcon]

The challenge we have here is that tools are limited and content is inconsistent. Meaning, when one closes and one opens, this causes the page to jump.

https://github.com/AlaskaAirlines/auro-accordion/blob/e0f237f5cc4ff3354c037b62fdc7d213487f774f/src/auro-accordion-group.js#L31-L34

This is the code that currently tries to maintain a central position, but like you point out, it's inconsistent. I'm hesitant to use a brute-force solution where we always move the accordion header to the top of the view.

[geoffrich]

Yeah, I'm not sure what the right solution is here. But I think it's an issue that a user can open an accordion and end up in the middle of the content, potentially missing anything at the top (especially when form fields are in the accordion). If there isn't a one-size-fits-all solution, is there a way to allow customization of this behavior?

Also, do we know how/if other accordion implementations handle it?

I also wonder if there's a way to delay calling scrollIntoView until after the height has finished transitioning. But idk if that's the root issue.

[blackfalcon]

I also wonder if there's a way to delay calling scrollIntoView until after the height has finished transitioning. But idk if that's the root issue.

That is what the feature I pointed out is supposed to do. We did so some reviews with other devs and design regarding the current solution. I am curious where this issue is stemming from? Is there a complaint or is this a personal observation? I don't know how to assign priority to this issue.

[geoffrich]

The current solution sets the height synchronously, but that doesn't mean that the height has finished transitioning when we start scrolling. So there might be something we can do there. But it's definitely a tricky issue.

This issue was raised by our UX designer when reviewing our contact tracing form, so it's not just my personal observation. The form fields for each passenger are in the accordion, and the concern is that guests might miss the field at the top (email address) if it's scrolled out of view after opening the section.

[blackfalcon]

i am putting the help-wanted tag on this one. While I agree it is something to be reviewed, unless a case is made, I can't see this being more of a priority than our other current priorities.

[Patrick-Daly-AA]

Needs input from UX on what the intended best behavior should be in edge cases like this.

[blackfalcon]

This issue was resolved to the best of our ability with the latest v3.0 release.