<nav> type attribute proposal


Nice proposal, big +1 from me. I also think type would be better than role here.

For Single Page Apps, (especially ones which are mobile focussed and PWAs - for e.g, twitter lite etc) I’m guessing page would be make sense more than site? In the case of SPAs where they have a nav which really is site wide, which one would be better to use? Would a different type value like spa be better? Or maybe accepting two values like type="site page" or just simply accepting page would do? Thoughts?


Isn’t the discussion of type vs role mute? Given how HTML maps to ARIA, if there would be native HTML support for this, we would need both a type attribute in HTML and corresponding roles or properties in the ARIA spec.

<nav type="site"> would likely map to ARIA role of something like "sitenavigation". That is, it would be the same as


Alternatively, it could map to ARIA role “navigation” with an ARIA property of aaria-navtype=“site”, e.g., <div role="navigation" aria-navtype="site">

Which approach is used on the ARIA side does not impact whether type is used in HTML.

Within ARIA, there are valid reasons for both approaches. I’ve personally found that altering the meaning of roles with properties to be problematic for authors. The issues that arise because aria-pressed and aria-haspopup cause role changes for elements with role button are exhibit A.


Not exactly. HTML mapping is set in the HTML AAM spec. They map to the platform’s accessibility layer. In Edge’s case that is UIA. Firefox uses IA2, etc. ARIA also maps to the a11y layer in the same way. There are some things in the HTML AAM spec (for example, the A element with href attribute) that states to use the same mapping as ARIA uses (in the a href case for the link role) as they represent the same thing. For <input type="tel"> for example, the spec says in UIA to map to the UIA “Edit” control type (which is actually the same as the “textbox” Aria role used by input type=“text”) and Localised Control Type of “Telephone”. While something like abbr has no similar ARIA at all and just says to map to the Control Type of “Text” in UIA.

(for some reason this isn’t showing in the UI that it is a reply to @Matt_King above)


In my mind, something like “spa” is methodology driven. It doesn’t really matter what technology or approach is taken, just what the navigation represents. I think it would either be “page” or “site” depending on what was being represented. If this idea is specced then maybe they could be given better names if there is a concern page and site don’t represent webapps. I almost suggested “local” and “global” respectively, but thought more literal naming would make it clearer. In some cases I think that maybe on single page apps, the top bar wouldn’t be a nav element at all, but is more like a menu in that it is a list of commands rather than links to navigate to. In others what I called “site” would make sense as they’re links to different pseudo pages (the entire view is changed with different content, rather than going to a different section of the same view/page


I wonder if “prevnext” is the same as pagination? Would there be a reason to map them differently? If you have say the next and previous buttons on the side of a Kindle, they’re still pagination controls in my mind, just a more compact form.

I can certainly see a use case for the external one. The MS sites for example have the global MS header (with a bunch of navigation links) and the site header that includes the nav for that site itself. Being able to skip the “network” nav would be nice usability benefit.

The for attribute proposal is interesting. HTML also uses different attributes, like there was a menu attribute for button type=“menu” to link it to the menu element, and datalist uses list. Not sure if this is adding more complexity though? You can also still use aria-label if need to add more context if you have multiple of the same type. I’m in two minds if I think the dots on sliders are pagination or just a sub part of a slideshow component. I’ve never marked them up that way, but the markup and semantics are fairly similar. But you could kind of argue tabs were pagination too.


I’d like to revive this proposal, as it has overwhelming support in this thread.

Presumably nothing has been done regarding this proposal ─ I can open an issue on WCAG’s GitHub for further discussion if wanted.


Although I think developers are getting more aware of a11y, I think these issues:

  • requires localization
  • different devs use different labels.
  • in some languages the label combined with the control type might not read out ideally, such as the correct order

…are major arguments to why we need this, and will be relevant for the forseeable future.

The very same issues quoted above applies to skip-links (https://webaim.org/techniques/skipnav/).

But using the proposed type attribute with <nav> to solve this for skip-links would require an extra <nav> element for just a single anchor, because we want the skip-link before the nav-<button> which should reside inside the main/site <nav> element which could be hidden until we press the nav-<button>, so we might end up doing this:

<nav type="skip-navigation"><a href="#main">Some localized text (e.g. "skip to content")</a></nav>

But the argument for using the role attribute allows to omit an extra <nav>:

<a href="#main" role="skip-navigation">Some localized text ("skip to content/skip navigation")</a>. This however, doesn’t solve the localized text for skip-links.

I too agree, we need to be able to define different types of <nav>, and while the same issues applies to skip-links I think skip-links needs separate handling.