[tabs] Concern about heading declarations as boundaries

[bmeck]

I'm coming in from https://daverupert.com/2021/10/native-html-tabs/ and noticed a couple of things that might lead to some delimiting confusion when not using delimiters/containers around the sections. I couldn't really find a central design doc around these after quite a few minutes of grepping around in search bars and poking around in directories.

1. role=heading aria-level=7 is a way to have more than <h6> level headings but in theory it could also be applied to elements. I'm guessing these would be picked up? In particular mixing <h1> and aria-level=1 would both have them be sections?

2. mixing headings is quite possible so tracking the "top level" heading value seems like it needs to occur but it can be confusing in poor markup scenarios like:

   1. having a heading level that appears to be out of order

<spicy-section>
  <h2>post A</h2>
  hi
  <h1>port B</h1>
  there
</spicy-section>

2. having a nested heading in a section

<spicy-section>
  <h1>movie 1</h1>
  <h2>cast</h1>
  Bob
  <h1>movie 2</h1>
  there
</spicy-section>

3. normally in screen readers tab titles and accordion summaries aren't treated as part of the heading navigation, I guess this would enforce that they are if they are using heading semantics to split up the interface. It seems like being able to have those without the header role would be nice since the common case today is not for them to be treated as headers in my own experience and looking in WCAG it doesn't look like they are normally.

[bkardell]

Hi Bradley! It can be hard to know if I'm understanding/responding to the right things without some back and forth, so apologies if I am misunderstanding anything (we'd love to have you come to an open-ui meeting or join the discord to more quickly make progress), but let me try my best to reply with what I can... I'll go in reverse order, I guess

normally in screen readers tab titles and accordion summaries aren't treated as part of the heading navigation

When tabs are presented as an affordance, the headings get a role - they wouldn't be headings anymore just as they woudln't be when viewing them. I don't want to imply that there's no questions here, but I think we're on top of them and doing the right things in terms of discussions and testing.

2. [kinds of heading use that wouldn't work]

Yeah, this is tricky to discuss I suppose, for two reasons. First is that this isn't necessarily a 'final proposal' but one which is implementable pretty close to what we are thinking today and in the end isn't that much different than some minor twists. To explain: Things are projected into shadow dom slots, and today those things need to be children, not descendants. A variant idea of this, one that some of us might even prefer, is to use something much closer to Hixie's original proposal which was a collection of <section> elements. That style of markup isn't possible with shadow dom today - however, realistically, this leaves open many of the same questions, for example: A heading level that appears to be a different (wrong?) level. Hixie's proposal seemed to count this similarly to our own - sort of just "well.. ok.". While displayed as headings, they'll work just as they do today - while displayed as tabs they'll just be tabs. Sort of "probably just don't do that?".

It might sort of "feel" like our current element would imply that you could wrap it around just any valid content, perhaps anything created with markdown, for example, but we also require your content to be in a single element, so not quite and again, the implication is about the same. You could, for example, write:

<spicy-sections>
  <h2>Thing A</h2>
  <div> 
     <p>....</p>
     <p>....</p>
     <h3>Thing A Point 1</h3>
     <p>....</p>
     <p>....</p>
   </div>

  <h2>Thing B</h2>
  <div>
    ....
  </div>
</spicy-sections>

And here only the children h2's would be spicy-section labels (potentially tabs or collapseable).

1. [what about role="heading"]?

It is, I think, a pretty good and open question. An earlier version of this allowed for that, but we were convinced to remove it for now. I don't think the door is closed on that.

[bkardell]

@bmeck the linked issue in the spicy-sections repo has some discussion related to your points that might give better clarity than my words above about what we may ultimately propose- we're just not there yet. If you have thoughts over there, they're very welcome.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.