Best Practice: Light DOM / Accessibility and component surfaces

[zeroedin]

This is sort of a loaded topic that I've been debating in my head for a while trying to figure out the "best" answer for my particular use case. The goal in building rh-secondary-nav was to have the Light DOM be as semantic, accessible, and critical stylable ( is that even a term? 🙃 ) from the start as it is above the fold critical page functionality. This included using the nav element at the root nav slot of the component.

Example structure:

<!-- Light DOM -->
<rh-secondary-nav>
  <nav slot="nav">
    <rh-secondary-nav-container>
      <a href="#" slot="logo">Logo Text or Graphic</a>
      <ul slot="nav">...</ul>
      <pfe-cta slot="cta"><a href="#">Get started</a></pfe-cta>
    </rh-secondary-nav-container>
  </nav>
</rh-secondary-nav>

<!-- Shadow DOM -->
<slot name="nav"></slot>
<rh-secondary-nav-overlay hidden></rh-secondary-nav-overlay>

After building out the component, and watching rh-footer evolve, I can't escape the wonder if my original approach may be overkill? Could the structure be simplified to:

<!-- Light DOM - Refactor -->
<rh-secondary-nav role="navigation">
  <a href="#" slot="logo">Logo Text or Graphic</a>
  <ul slot="nav">...</ul>
  <pfe-cta slot="cta"><a href="#">Get started</a></pfe-cta>
</rh-secondary-nav>

Whereas the shadow dom takes care of adding the nav element on upgrade and subsequently removing a role="navigation" attribute that is only there in case of a failed upgrade to maintain accessibility semantics.

<!-- Shadow DOM - Refactor -->
<nav part="nav">
  <slot name="base">
    <div class="container" part="container">
      <slot name="logo"></slot>
      <slot name="base"></slot>
      <slot name="cta"></slot>
    </div>
  </slot>
</nav>
<rh-secondary-nav-overlay hidden></rh-secondary-nav-overlay>

All while being keenly aware of:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/navigation_role

It is preferable to use the HTML5 nav element to define a navigation landmark. If the HTML5 nav element technique is not being used, use a role="navigation" attribute to define a navigation landmark.

This structure is currently being utilized in rh-footer whereas the <footer> tag is embedded in the shadow dom. I also wonder if it should implement the role="contentinfo" on its host tag and remove it on upgrade?

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/contentinfo_role

The contentinfo role defines a footer, containing identifying information such as copyright information, navigation links, and privacy statements, found on every document within a site. This section is commonly called a footer.

This change would also help to reduce the need for the container component which was really just an area to apply additional slots. Overall reducing the custom tags needed in the light DOM.

What are we defining as the best practice here? Keeping in mind accessibility is the #1 concern then critical styles then finally FED DX.

A potential CSS issue with the refactor approach could be the need to "restyle" the layout in the critical light DOM CSS from a grid on the rh-secondary-nav tag to a grid on the shadow dom .container class after upgrade. I would have to experiment to see if that would cause any reflow issues.

[bennypowers]

fewer elements is nice
I'd like to hear from Kelsey about the a11y questions. I'll poke around too

[markcaron]

IMO, role="navigation" is acceptable, especially given our constraints and the fact that the component would upgrade to the preferable <nav>. The ARIA role should be sufficient for accessibility, and I like this simpler approach.

As for the <footer>, we should definitely upgrade our docs to reflect the role="contentinfo" implementation. So, thanks for noticing that!