Support custom attributes on a section's auto-generated wrapper tag

Online Store and Theme Development
1

Short description of issue

Feature request: support custom attributes (e.g. role, aria-*) on a section’s auto-generated wrapper tag

Link to Shopify Store

Reproduction steps

  1. Create a section schema that uses the tag/class keys to auto-generate the wrapper element:
{% schema %}
{
  "name": "Header",
  "tag": "header",
  "class": "header"
}
{% endschema %}
  1. Try to add any other attribute to that auto-generated wrapper (e.g. role="banner", aria-label, data-*) directly through the schema.
  2. There is no schema key that supports this — only tag and class are available.

Additional info

This is a real limitation for accessibility work: landmark roles like role="banner" / role="contentinfo" are a common requirement on header/footer sections, and there’s currently no supported way to add them through the schema.

The only workarounds are giving up the schema-driven wrapper entirely ("tag": false + hand-writing the tag), or setting the attribute client-side via JS after render — neither is a real fix.

Suggestion: support an attributes key, the same way class already works, e.g.:

{% schema %}
{
  "name": "Header",
  "tag": "header",
  "class": "header",
  "attributes": {
    "role": "banner"
  }
}
{% endschema %}

This would also open the door to fully custom data-* attributes on the wrapper (e.g. JS hooks, analytics, testing selectors).

Is this something that could be added, or is it already tracked somewhere?

What type of topic is this

Feature request

2

Is this not sufficient in that case?

<div id="shopify-section-sections--27697696801099__header" class="shopify-section shopify-section-group-header-group site-header">
  <header role="banner" class="...">
  </header>
</div>

I might be wrong, just what I’ve been doing.

Actually thinking about it, I think role="banner" is redundant in the <header> case, as I’ve always learned “don’t use ARIA if native HTML does it” - which header does AFAIK.

But there’s definitely other use cases, where I think my above example should be sufficient.

3

Thanks for the suggestion @curzey ! That said, this is essentially the same as the "tag": false + hand-written wrapper workaround I mentioned in the original post.

It works, but it means giving up the schema-driven tag/class generation entirely for that section.

I’m hoping for a cleaner, schema-level way to add attributes (like the attributes key I proposed), so we don’t have to trade away that convenience just to add a role or data-* attribute.

Regarding role="banner" being redundant on <header> - that’s not entirely true in practice. In the accessibility audits we’ve received, adding role="banner" explicitly is still recommended, likely because the implicit landmark role only applies when the <header> is not nested inside article, aside, main, nav, or section - which is a fairly easy condition to accidentally break in a themed section structure. So having an explicit way to set it would still be valuable.

4

Aight, I think I missed that point of your post.

Good to know regarding explicit roles - I’m no expert on that.