First, thank you for improving the accessibility of the Accordion, Tabs, and their nested counterparts. The improvements are very much welcomed. Here are a few things that can be implemented to improve accessibility further.
Accordion and Nestable Accordion
For the regular accordion:
The role="presentation" should be on the <ul class="brxe-accordion">, not the li. Doing that would convert the ul > li into a regular div. In the case of the nestable accordion, there is no need for the role="presentation" as it is already a div.
The accordion trigger should have the structure h3 > button > span.text + span.icon. Currently, the button is wrapping everything. Ideally, a button element should only contain phrasing content.
Where possible, use the semantic HTML for the button rather than a <div role="button">.
Make the default heading tag an <h3> rather than <h5>.
Tab and Nestable Tab
In the case of the tab and nestable tab, here are a few suggestions:
The role="tablist" should be on the <ul class="tab-menu">, not the wrapper div.
The role="presentation" on the <div class="tab-content"> isn’t needed because it is already a div.
The home and end keys on the tablist should only move the focus to either the first or last tab item; they shouldn’t also move the page up or down.
Builder Accessibility
Thanks for including the focus state for the builder tab items, but I suggest that it includes a visible focus outline rather than relying on colour change only. I would also recommend possibly using Tippyjs for the tooltip to be announced properly.
Thanks a lot for your detailed feedback! I’ve added your suggestions to our to-do list, and we’ll aim to cover as much as possible.
Some items, like the h3 > button > span.text + span.icon structure for accordions, may not be feasible due to backward compatibility, but we’ll look into it.
Regarding the Tippy.js suggestion, we’re trying to avoid adding dependencies. Could you share what improvements are needed with our current tooltips so we can address any accessibility issues without extra libraries?
Thanks again for your input, it’s really appreciated!
Yes, I figured it would be difficult to change the HTML structure.
Regarding the tooltip, here are a few potential problems related to the current approach:
I noticed that the tooltip disappears if the browser zoom is 200% or above.
Side note: the top bar items should ideally be buttons or links, depending on their purpose, wrapped inside the <li> tag. However, this leads to problems with the pseudo-element not being announced by screen readers. An example is the WordPress logo not being announced.
It is recommended to use text in the DOM rather than relying on pseudo-elements, as some assistive technologies ignore content in pseudo-elements in certain cases.
Thanks for the update. I did a quick test during my latest YouTube livestream and there are still some minor things that need improving in the nested elements.
Nested Accordion
There is no longer any <button> element in the accordion title, so the whole element is not keyboard-focusable. That can probably be fixed easily by the user but it would be nice to include the default as a button instead of a <div>
The aria-labelledby on the individual tab panels are referencing the wrong tab ID
I believe most of the other things are in good shape. (I still secretly wish we could make the button to be the child of the h3 not the other way round. But I understand the limitations.)
Thank you very much for the feedback! Yes looks the <button> is now missing, great catch! I’ve added all your suggestions to an internal bug ticket. I’ll also revisit the possibility of making the button a child of the heading, though last time we reviewed it, it seemed unfeasible without causing a breaking change.
May I add something I noticed after the update? Actually aria-expanded=“false” doesnt appear on the first load of the accordion. Here you have a screenshot:
The problem is because I have search form inside tabs, and problem is when I put height on search icon. If I don’t type height there is no error on Google Page speed, but button has smaller height instead of input type.
I have issue with this and Google page speed. When I have nestable tabs on page in results I am getting error on accessibility (! Touch targets have sufficient size and spacing. Error!)
I tryed what I found here on forum with JS script and adding tabindex with 0 value, I tryed to add ul HTML tag to Tab menu, and li on divs which contains texts but not successfull. Is there something what I missed? hmmm. When I set section with tabs to display:none and test it on Google page speed all is perfect. So, my conclusion is that tabs causing problems.
thank you for all the details 
