Display template: Discuss removing h3 tag

[plocket]

No description provided.

[nonprofittechy]

I'm fine if we find another appropriate semantic element to use in its place. Just a span is worse than the wrong level of heading for a screen reader AFAIK.

[plocket]

Looking into what would be semantically appropriate. I think not a heading. The collapsible display templates don't have headings at all, so at best the current behavior is inconsistent. And do users want these as headings on their page? Hoping we can find something more generally useful.

[nonprofittechy]

Before investing too much, we should make sure we can research any existing guidance focused on this pretty common component. And also consider testing with JAWS so we know our change makes it better.

[plocket]

Yes, research is my intention :)

Edit: Maybe ChatGPT knows...

[plocket]

Results so far:
<details> and <summary> seem to be becoming more standardized and accepted for "[progressive] disclosure" functionality. They have their own quirks, but everything does, and we probably don't have enough experience to roll our own (from what I've seen of our HTML). This seems to be a more recent opinion since the element has more browser support and more consistent behavior now. I think <details> the closest description to the way I've seen our collapse template being used, even when multiple are used on a page. I think I haven't seen it being used for accordion-like behavior, though I haven't found a good definition for what is or isn't an accordion. Because we provide each collapse_template as a singleton, though, I don't think we're able to make an accordion, which I believe needs to have more than one item in a container.

Some people do distinguish between <details> and an accordion for some reason, but it's not completely clear why. Headings might to be one important part of accordions. There's no element for an accordion, so if we make our own (which I'm reluctant about) this w3 page seems to outline some kind of as yet unstandardized example. It says to not use it in production, or maybe to do more research before using it in production. I'm not sure how to do more thorough research than they've already done, so I'm not sure what to do with that. Note that hidden accordion content does not get picked up for SEO, but I think da pages in general don't, so not sure that matters much.

A caveat is that summary is basically a button role and that eats the semantics inside it, meaning a heading can't be in there. We're already doing that with our own current HTML, though. I think summary can't be surrounded by a heading either - summary has to be the first child of details.

Note: We're also using aria-expanded on a link, which at least one article discourages. It describes testing with users, including accessibility.

[To use icons with summary instead of its standard arrow would indeed take different implementation and some thought.]

[BryceStevenWilley]

Super great research! I'd seen one or two of those articles, but really useful to have them all in the same place.

Some specific responses:

I think I haven't seen it being used for accordion-like behavior, though I haven't found a good definition for what is or isn't an accordion. Because we provide each collapse_template as a singleton, though, I don't think we're able to make an accordion, which I believe needs to have more than one item in a container.

My understanding from reading all of the resources you provided is that an accordion is just a section with a show/hide, that can contain arbitrary HTML (like other headings, etc.) It looks like <summary>/<details> it only encouraged with plain text (or anything not structural), actually just details.

[To use icons with summary instead of its standard arrow would indeed take different implementation and some thought.]

Is a very good thought, I think the arrow customization is a big part of the widget.

That said, this would be a pretty big refactor, for all of the reasons you've mentioned. The options as I see them:

• use summary/details (big change, might not be the right choice)
• keep our own structure, but use a button instead of a link (following Scott's example)
• minimal (doesn't fix all of the issues), stick with just changing the h3. I would think that most people don't intend to use this as a header, and I think just a bold tag would be good (with some testing as well).

[plocket]

It looks like <summary>/<details> it only encouraged with plain text (or anything not structural), actually just details.

The content can technically contain anything you want from what I can tell. I hadn't yet found anything that encouraged only plain text content.

The options as I see them:

Other item for the [options] todo: Avoid putting anything semantic inside a button or a button role, especially if we stick with some kind of heading tag.

[plocket]

We can also do this piecemeal, starting with the lower hanging fruit.

[BryceStevenWilley]

The content can technically contain anything you want from what I can tell. I hadn't yet found anything that encouraged only plain text content.

From the Dave Rupert post you linked

it eats the semantic content of elements inside it. Here’s a contrived example with headings:

h1 + button // ✅ H1 will show up when navigating by headings
button + h1 // ❌ H1 will not show up when navigating by headings

And from the Scott O'Hara post:

just because something is allowed in HTML, that doesn’t mean it’s going to be a good idea for all users

It can technically contain anything, but the main points I got from the stuff you linked were that summary will remove anything semantic (I said structural earlier) from the details. That's why I said it encouraged plain text; no one explicitly said it, but given it eats semantic content for accessibility, all that remains is (roughly) plain text and divs, no headings, bullets, structure, etc.

Other item for the [options] todo: Avoid putting anything semantic inside a button or a button role, especially if we stick with some kind of heading tag.

I'm not sure what you mean here; if you are saying that we should not include anything semantic inside the template contents for if we eventually change to summary / details, I'm not sure that's the best solution, given there's been no rules about that so far. The more I think and read about it, summary/details doesn't seem to be the right option.

If we role our own, like the W3C example, we can put almost all of the semantic content outside the button, so I don't think we need to worry about that.

this w3 page seems to outline some kind of as yet unstandardized example. It says to not use it in production, or maybe to do more research before using it in production. I'm not sure how to do more thorough research than they've already done, so I'm not sure what to do with that

TBF, that disclaimer is put in front of all of the examples that I've seen. I think it's meant to be a "don't use this without testing", but it's a great starting template for us.

[plocket]

It can technically contain anything

I thought you meant the whole details element - the non-summary part can contain other stuff. I agree about summary

Other item for the [options] todo: Avoid putting anything semantic inside a button or a button role, especially if we stick with some kind of heading tag.

I'm not sure what you mean here; if you are saying that we should not include anything semantic inside the template contents for if we eventually change to summary / details, I'm not sure that's the best solution, given there's been no rules about that so far. The more I think and read about it, summary/details doesn't seem to be the right option.

All I mean is that currently we try to put the h3 inside an element with the button role and we should change that. That is also just about summary. Everything else can still have semantics and everything. And everything can be styled.

I'm still leaning towards (eventually) details/summary, but maybe we should discuss this real-time as we seem to be getting our wires crossed.

[BryceStevenWilley]

I see now that I was getting details / summary backwards, and thinking that the button somehow wrapped over all of the details, even when expanded. That, combined with my misunderstanding of what Adrian was implying an accordion was led me way off the rails, apologies.

With that calibration, I'm either-or between details / summary and rolling our own, with some testing between the two. Agreed that we probably don't need to discuss too much more here.