Add accordion to faq.

[nikoshell]

🖼️ Preview available 🖼️ : https://ep-website--1073.org.readthedocs.build/

[europython-society]

Preview available

Key	Value
url	https://ep2025-faq.ep-preview.click
last update	2025-04-01T09:00:08.359Z

[nikoshell]

#984, let's keep it open, I could miss understood issue.

[hypha]

hmmm how does it close #984? 🤔

[hypha]

There was some discussion on this before. Making everything in the FAQ into accordion sure looks nice. But I don't think we know if it reduces functionality, because potentially, many users will prefer to Ctrl+F. This was the reason why I was thinking of only putting accordion to explain session types #989 for now.

[clytaemnestra]

• Ctrl+F seems to work with the accordion as well - it opens automatically, so I think that's okay functionality-wise
• I don't think it's closes #984 from the content perspective, as the accessibility page is not ready yet, but it provides a component that can be reused there and it does solve it from the technical side -> therefore, I'd keep #984 open so we don't forget to link the accessibility page to the FAQ

[clytaemnestra]

@hypha could you test it out and let me know if the search works for you as is? Or did you mean something else by it?

[hypha]

Ctrl+F seems to work with the accordion as well - it opens automatically, so I think that's okay functionality-wise

Not for me on firefox.

[clytaemnestra]

I did some research, and it turns out Ctrl+f doesn’t work in Firefox with the accordion component.

Taking a step back, let’s describe the problem we're trying to solve:

1. The main purpose of the page is to help users find information
2. We want to avoid having a wall of text: too long FAQ pages are unreadable
3. We want to allow users to use Ctrl+f. I think that’s a very important feature for an FAQ page, since the whole point is to help people quickly find what they’re looking for

That said, I’d think how to satisfy all requirements, so it's functional, but also looks nice, whether we use accordion or something else.

An idea: @nikoshell, @hypha, what do you think about adding an Expand all and Close all button that’s clearly visible to users?
That way:

• if they’re on Firefox and want to search, they can expand everything first and then use Ctrl+f;
• if they're on Chrome/Safari/something else the search with work without having to use that button, so all good;
• if they don't need to search, they can skim through the questions and open the one they're interested in.

By the way, I tested the search box too, and it does find elements in Firefox.

[clytaemnestra]

Apparently GitHub was solving a similar issue, not sure if it's helpful, but leaving here for inspiration: https://github.blog/engineering/architecture-optimization/crafting-a-better-faster-code-view/

[hypha]

what do you think about adding an Expand all and Close all button that’s clearly visible to users?

Was thinking the same. I reckon that should work. But might want to test how such a button behaves with a screen reader.

[nikoshell]

If we consider accessibility we should use existing solutions which implements components with all goods to not invent the wheel again as we don't have so much resources.
In current state of the website there are less accessible places than faq, so would be nice to start with main page.

If we are able to decide which level of accessibility we wanna follow I will do that by default it will just affect time of features delivery.