Unable to access toggle button options using keyboard navigation.

Oh wow i thought this worked once. Promoting!

Digging into this a little.

How about changing this to a dropbutton with "collapse" as the first item? It's an existing UI pattern in core, I don't see the benefit of having a separate widget for basically the same thing.

Dropbuttons currently only allow links, this issue would have to be resolved first: #3057577: Provide a way to add Buttons to Dropbutton

Thank you @DamienMcKenna for looking into this.

We intentionally added our own element because Core was too limited in capabilities and there were many issues. This allowed us to evolving the UI with great positive user feedback based on the resulting reduced UI.
Also the whole APIs are designed around the additional feature that we can ship a drop button without a default.

The element also allows easy customization in themes and change the look of such a widget, like Thunder does.
This is a UI contract we can't beak at the current stage.

If you're really not happy with this, i would need to spend some time searching for issues and the mock-ups and design studies we did when our primary goal was to reduce the UI as much as possible. It's spread in multiple presentations and issues about Paragraphs UI evolution.

Thanks for the response.

I think it would have been a better idea to fix the dropbutton so it worked with submit buttons rather than building another widget, but I do appreciate not wanting to change it now.

I feel it is important to discuss this more and provide more background.

When we decidided to add the own element, the dropbutton link limitation was not yet relevant or not yet identified. We added all the extensibility later and were very happy to add so much functionality without additional clutter.

The default action really made zero sense for many cases. One problem was that some actions were not always available. So the default action was randomly the next available action, leading to UI inconsistency and confusion.

So again, the identified problem was for our UX that it was not possible to provide a dropbutton without default operation. And we proofed that it is a major ux improvement. Our UI is now very stable and extensible and much more powerful with less visual noise and less initial complexity. We spent more than two weeks with the mockups to develop this answer.

Material Design offers such a menu item. And then Material Admin theme puts ALL default operations into the „...“ button. That‘s also wrong if you promote intentionally a default operation. It is now a click more away. That‘s why we manage both explicitly. (Maybe they changed it meanwhile?)

And core should pick this idea up as well.
When we started, it was not the right moment to propose to expand an element like the dropbutton or define a superior one. Maybe we should check with the Claro team now.

I moved the dropbutton idea into its own issue: #3096703: Convert widget actions to dropbutton

About the solution proposal:

Adding a label with visibility-hidden would lead to duplicate speech of label plus link/button text.

If you test this, please check with a screenreader, most easily there is one with your phone. And btw the button also allowed us to majorly improve the mobile content creation experience.

Maybe simply annotating tabindex attribute would solve the problem.

I checked this problem here a bit more.

The buttons are technically reachable by tabs.
They are not, because if you move away from the "..." button, the "close" action is triggered, so the actions are focussed while they are visually hidden.. caused by this:

paragraphs.actions.js

        $toggle.on('focusout', function (e) {
          $this.removeClass('open');
        });

The patch attached fixes it with a timer checking the resulting active element... Maybe we should move the method into the behavior?

Ah this is much better JS style. ;-)

And committed. :-)

Writing tests for the tabbing seems currently too much work, i prefer to simply fix this now as there is no regression identified. More discussions over at the parent Accessibility meta.

Oops, forgot to tag :-)

+++ b/js/paragraphs.actions.js
@@ -28,8 +28,13 @@
+          timeoutID = setTimeout(function () {

The browser is throwing an error about timeoutID variable not being set.

paragraphs.actions.js?0:32 Uncaught ReferenceError: timeoutID is not defined
    at HTMLDivElement.<anonymous> (paragraphs.actions.js?0:32)
    at HTMLDivElement.dispatch (jquery.min.js?v=3.4.1:2)
    at HTMLDivElement.v.handle (jquery.min.js?v=3.4.1:2)
    at Object.trigger (jquery.min.js?v=3.4.1:2)
    at Object.simulate (jquery.min.js?v=3.4.1:2)
    at HTMLDocument.i (jquery.min.js?v=3.4.1:2)
(anonymous) @ paragraphs.actions.js?0:32
dispatch @ jquery.min.js?v=3.4.1:2
v.handle @ jquery.min.js?v=3.4.1:2
trigger @ jquery.min.js?v=3.4.1:2
simulate @ jquery.min.js?v=3.4.1:2
i @ jquery.min.js?v=3.4.1:2

I think we don't need to assign the function to a variable.

Yeah thx, fixed. Again. ;-)