htmgarcia
commented
2 years ago Unfortunately, the Accordion will currently not work correctly if the Accordion header is wrapped in an outer element, e.g.
<h2><a class="ui-accordion-header"></a></h2>.
https://lab.dotjay.com/tests/jquery-ui-accordion-keyboard-accessibility/
I can confirm this:
The currently active header has a tabindex of 0. The other headers have a tabindex of -1. This makes it so that when you tab into the accordion, the next tab press will move out of the accordion (the entire accordion is treated as one component). The arrow keys should be used to move between headers when the accordion is active.
https://bugs.jqueryui.com/ticket/4023
All of the implementations use ARIA role=tablist and role=tab to convey expandable and collapsible accordion nodes. The problem with doing this, is that the insertion point for new accordion content is included within the container with role=tablist. Meaning that, if accordion content includes additional ARIA widgets, such as a real Tab control that uses ARIA role=tablist and role=tab to convey a nested ARIA Tab control, it is impossible for screen reader users to determine the difference between an accordion node and one of the nested tab controls, because both are announced as “Tab”, nor can screen reader users determine the proper order and level of nested Tab controls for the same reason, since no level information is conveyed.
Additionally, the Sortable Accordion implementation is not accessible for screen reader and keyboard only users.
https://www.levelaccess.com/jquery-ui-accessibility-analysis/
We only can reach the first accordion. Seems related to #66