Accordion Type non-heading option (accessibility issue)

[gregrgay]

Currently the Accordion content type editor has options for creating H2, H3, and H4s for the accordion toggles.

There should also be an non-heading option such as P or SPAN. When an accordion is inserted into a page of content, the heading will often break the surrounding document structure (i.e. the heading sequence), inserting a heading where none is expected. Sometimes the author can predict where the accordion will be placed, and guess which heading to use so it fits the heading sequence on the page of content.

Other times, maybe most times, like in the middle of a section of content made up of several paragraphs, that say starts with an H2, plugging an accordion following the first paragraph in that section, and selecting an H3 in the accordion editor, it would fit the sequence after the H2 for that section, but then that H3 becomes a heading for the paragraphs that follow, which structurally are still children of the section's H2 heading. This will create confusion for some screen reader users. Currently the only place the accordion can be placed safely, without breaking the document structure, is at the end of a section, or the end of a page.

Screenshot of the accordion heading selector

By providing a non-heading option for the accordion, it gives the content author the option of placing the accordion anywhere in the content, without affecting the document structure.

[joshuaboele]

Agree a lot with this sentiment, however I'd like to propose to change the toggle to a <button> or <a> element instead, and possibly nest the tags for the text within these buttons. This would also make it so the toggle itself is less reliant on aria features such as role=button. IMO we should strive to use native functionality wherever possible.