Accordion headlines?

Support
#1

Hi,

A couple of years ago I submitted this question.

In Accordion -> Header in Cornerstone, I can change the HTML-tag from “button” to “H3” - which would be very appropriate for headlines in an accordion. However - if I do this, it will remove the aria-role (button) and get errors in various tools. The mouse curser will also go from a clicking hand to just an ordinary arrow which will confuse users.

I will repeat what I mentioned in my old post; accordions is great for lots of text/content but without headlines, it’s just a complete mess for Google and LLM’s. For SEO/GEO etc. it’s pretty important and it’s standard in all other builders. Could you please consider fixing it soon?

#2

Hello @Kobber,

Thanks for updating in!

When switching from <button> to <h3> HTML tag, the role=“button” on the Accordion header stays the same.

image
image947×569 32.9 KB

You just need to add custom inline element CSS to make sure that there is a pointer.
image

$el .x-acc-header {
  cursor: pointer;
}

Best Regards.

#3

Right now I have to set all headers in my accordions manually to H3. If I use the HTML tag choice in Accordion -> HTML tag instead, I get errors from Google.

I got help from Claude to translate the issue:

The FAQ accordion component in the theme currently renders its headers as <h3> elements with role="button" applied directly:

html

<h3 id="tab-e430-e265" class="x-acc-header" role="button" type="button" 
    aria-expanded="false" aria-controls="panel-e430-e265" 
    data-x-toggle="collapse" data-x-toggleable="e430-e265">
  Hvad får man med?
</h3>

This is flagged as an accessibility error (“ARIA role should be appropriate for the element”) because a heading element is being overridden to behave like an interactive control. There are two problems with this pattern:

  1. Semantic conflict : <h3> is a heading element. Overriding it with role="button" strips its native heading semantics for assistive technology and search engine crawlers, while also not giving it the native behavior of a real button (keyboard activation via Space/Enter, focus handling, form-safe type attribute, etc.).
  2. Invalid attribute : type="button" is only a valid attribute on <button> elements. On an <h3> , it does nothing and is itself flagged as invalid markup.

This matters beyond Lighthouse/Google’s audit — it directly affects how screen readers and AI browsing agents parse the page. Both rely on the accessibility tree to identify headings for navigation (“jump to next heading”) and to identify interactive controls for actions (“click this button”). An element that’s neither a proper heading nor a proper button breaks both use cases.