One thing to keep in mind, it's a flawed paradigm to have only one tab stop for an accordion control, because the content is rendered inline with the triggering element. This causes major accessibility issues for keyboard only users when expanded accordion panels include many active elements, since it is then impossible to maintain a contiguous tab order that matches the reading order of the page.

Also, accordions are simple control types, and should not need to enforce a particular mode of navigation for users such as Applications Mode, which is confusing when all you want to do is just expand something and read the content. This is what happens when you use ARIA Tab markup on an accordion for example, which I don't agree with doing for this reason.

The OAA examples work quite ok actually, though I do not necessarily agree 100% with the markup.
aria-expanded should be on the buttons that control the display/hide of their associated panels rather than on the panels themselves.
(keep in mind, if we do this, the name of the button .. in this case its value property, should not change, it should just be "topic 1" and aria-expanded should be updated to indicate visibility of the associated panel).
Also I do not think the focus should move from the button to the panel it controls, especially not when the content is inline to the button (comes right after the button, in content order).
You seem to be looking for an accessible accordion pattern (or a variant thereof).
Simplest example can be found here:http://www.3needs.org/en/testing/code/aria-expanded.html
An accordion example can be found e.g. at:
https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-tabless-multiselect-accordion
Cheers