Make accordion titles headings by default, and consider dropping default list

[mbgower]

Use of heading

The default variant of a Carbon accordion does NOT have a heading role assigned to the title. The ARIA Authoring Practices does. It reads:

Each accordion header button is wrapped in an element with role heading that has a value set for aria-level that is appropriate for the information architecture of the page.
If the native host language has an element with an implicit heading and aria-level, such as an HTML heading tag, a native host language element may be used.
The button element is the only element inside the heading element. That is, if there are other visually persistent elements, they are not included inside the heading element.

Note that despite this wording, the usual way to construct for these is using html heading tags, as follows:

<h#>
<button>
Title
</button>
</h#>

The aria accordion example uses this construct.

As part of the accessibility review of Carbon components, we added guidance on the Accessibility tab for designers to specify headings, to reinforce when they should be implemented as such. If the heading variant were adopted as the default, we would need to update this guidance.

Use of list

Conversely, the default Carbon implementation DOES makes each accordion a list item in an unordered list, while the The APG does not use a list. Lists are not technically wrong, but are arguably less valuable for most users of ATs than the use of headings.

A suggested approach is to use headings and not lists in the default Carbon accordion. You could offer a variant where headings are dropped and lists are added. This would mean that accordions inherit some kind of structure that better matches their visual structure on the page.

I would suggest that if you want to retain an option for lists, the list accordion variant could be styled differently than the headings default (i.e., body-sized text for the title; perhaps the entire accordion structure indented, like a standard list is. The advantage to this is that designers can visually differentiate between the variants when choosing in prototyping tools like Figma. Since the variants are visually different, it reduces the need for designers to annotate which accordion variant to use, and also greatly increases the chance that the right variant will be implemented by developers, even if there is no annotation.

An example of accordions using different styles on the same page is actually offered on the APG accordion example previously mentioned. The example is preceded by a Note, which is itself an accordion, styled differently but not given a heading.

A few comments about accordion lists are stated in #9853

[mbgower]

BTW, the use of headings is supported by existing wording in the Content section of the Usage page

Each title should be wrapped in a role heading (h1-h6) that is appropriate for the information architecture of the page.

[mbgower]

I have a related issue open on not using lists by default #9853