<nav> type attribute proposal

Nav type attribute

Disclaimer, I work on the Edge Web Platform team, but this proposal does not imply Microsoft’s support or lack of for this proposal, or any intent to implement. It is an individual proposal meant to start discussion on if it is a good idea or not.

Problem statement:

HTML5 added the nav element. One problem with this is there is author confusion (including sometimes this author) on which sets of links should use nav. The spec has changed at least once to address this and it is still not concretely clear: http://html5doctor.com/nav-element/ .

For example the spec states:

The element is primarily intended for sections that consist of major navigation blocks

…but major may mean different things to different people.

Beyond developer experience, the current use of <nav> is probably inconsistent for Screen Reader users. A nav element is a landmark, so if devs use it differently you get different experience for the same types of navigation. If you have a bare element a screen reader may just announce navigation.

Some devs that are more accessibility aware may label with aria-Label, such as Breadcrumbs component in the Salesforce Design System, A11y Style Guide, or the edge.ms dev site.

However, this:

• 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

Proposed solution:

If we add the type attribute (or similar), we can:

• Explicitly define in spec correct/recommended use cases, while still allowing bare nav, or nav with aria-label for those not in spec
• Have localization built into the user agent so labels for same units of navigation are consistent

Example values could be:

• site: Site wide navigation, usually found inside header element. Maybe this could be inferred if in header closest to root if no type.
• page: Navigation for the current page. The ones usually found in a side bar. Not sure if this would be same as TOC or should be another for that, as the whole document/article is not always on one page
• breadcrumb: Breadcrumb navigation
• pagination: Pagination controls often found at bottom of articles

My thinking is this would do something similar to <input type="number"/>, etc. where the A11y layer sets a localised control type. “Breadcrumb navigation”, or “pagination” for example. This would probably be defined in HTML AAM.

Currently all nav are part of landmark navigation. If this was included, they could be mapped differently if needed, such as if some more minor nav types shouldn’t be a landmark. Custom behaviour could also be applied if desired, and could also perhaps be used as an additional hint for content adaption such as browser reading modes, etc.

In the future it could also be extended to allow different contents for different types, such as maybe restricting contents of nav type=“breadcrumbs” to a list, or introducing new markup such as the equivalent of aria-current to notate the current breadcrumb.

I like this idea. It could offer greater consistency for users, using a concept/attribute that is very familiar to developers.

Example values could be:

• site: Site wide navigation, usually found inside header element. Maybe this could be inferred if in header closest to root if no type.
• page: Navigation for the current page. The ones usually found in a side bar. Not sure if this would be same as TOC or should be another for that, as the whole document/article is not always on one page
• breadcrumb: Breadcrumb navigation
• pagination: Pagination controls often found at bottom of articles

I’d suggest having different tokens for “page” and “toc”, because they represent different use cases. Referring to the page navigation of a website as its table of contents would not be a good fit IMO.

A couple more token suggestions:

“footer” for the navigation blocks found at the bottom of pages. The ones that usually contain links to terms/conditions, a11y statements etc.

“social” for the navigation blocks that contain the ubiquitous social networking links. This one might be stretching things a bit, but the appeal of consistency across sites is strong!

“mobile” for mobile navigation blocks. In some respects mobile isn’t a type of navigation (a page remains a page whichever device you look at it on), but it might set up expectations about the nature of the navigation therein (hamburger menus etc.). It might also offer a useful styling hook for responsive design.

My thinking is this would do something similar to ||, etc. where the A11y layer sets a localised control type. “Breadcrumb navigation”, or “pagination” for example. This would probably be defined in HTML AAM.

Yes, that would make sense.

Currently all nav are part of landmark navigation. If this was included, they could be mapped differently if needed, such as if some more minor nav types shouldn’t be a landmark. Custom behaviour could also be applied if desired, and could also perhaps be used as an additional hint for content adaption such as browser reading modes, etc.

Yes, rationalising the navigation blocks included in standard landmark navigation would be good. It would also mean ATs could offer different ways to navigate to different types of navigation block (a dialogue to choose between all types, or specific shortcuts for navigating to specific types for example).

This might be a stupid suggestion, but maybe role could be used instead? Something like <nav role="doc-toc"> is already available. We have doc-toc as a subclass of navigation, this seems like a model that could extend to other options.

(This is a reply to Robin; the UI does not make that clear to me) In concept I like this, though I think if that happens we would need to mine the ARIA DPub document for more (such as doc-index, doc-pagelist, and doc-toc) and still need to generate new ones to cover some of the common scenarios on the web (such as breadcrumbs).

That also means some would be pre-prended with doc- and some would not.

As a comment on the original proposal, I see value in this. When conducting training with people who are using <nav> and have skills around accessibility and ARIA, I am asked about how to differentiate navigation blocks. The localization aspect of aria-label has been cited as a frustration point because of the limitations of some of their tools.

One of the appealing things about using the @type attribute as opposed to the @role attribute, is that it’s native to HTML, and as such it’s familiar to developers.

The proliferation of ARIA roles is making it harder for authors to know which role to use and when/when not to use them, and we’d need to mint a whole bunch of new roles to cover this use case.

I don’t think type is more native than role. We already have role available on the element, just adding a few more ARIA doesn’t strike me as particularly problematic. Besides, having two attributes serving the same purpose of refining the semantics of the holding element opens the door to conflicts: what does <nav type="breadcrumbs" role="doc-toc"> mean?

I respond as editor of EPUB 3.1 and editor of DPUB-ARIA.

EPUB requires a type attribute on nav (see https://www.w3.org/Submission/2017/SUBM-epub-packages-20170125/#sec-package-nav). The only one that is a requirement for a valid EPUB is epub:type="toc". The other type that is extremely popular is pagelist, to identify pagination in a publication. When we drafted DPUB-ARIA 1.0, we included these two as ARIA roles with the intent of the roles eventually replacing the epub:type vocabulary. See https://www.w3.org/TR/dpub-aria-1.0/#doc-toc, https://www.w3.org/TR/dpub-aria-1.0/#doc-pagelist, and the related https://www.w3.org/TR/dpub-aria-1.0/#doc-pagebreak (which can provide visual page numbers/markers along with a list of page numbers). I can get statistics on how widely these, and other terms, such as list-of-tables, are used as well.

DPUB-ARIA 1.0 was the first spec to exercise the WAI-ARIA extension mechanism, but it won’t be the last. Whether roles are prefixed should not be a reason to not make use of useful specs. Prefixing was a hot debate that went on for months. If the result of the prefix is that people won’t use the terms, I will take that back to the team.

I think re-using role would end up being a much better solution for developers. They’d then be using an attribute that has wider uses to improve a11y then they currently do. Creating “yet another attribute” means it is just one more thing that eventually needs to be discovered, understood, and then remembered to get applied in the future.

I often come across websites with broken semantics because the @role attribute has been misused. I don’t think I’ve ever come acros a website where the @type attribute was misused though.

I disagree with the idea of using role here.

In all other instances of role, it’d be used to change the underlying semantics of what the element is. But here the goal is to not change the fact that this is a navigation, but to better define the purpose of a particular navigation element.

I quite like the proposal of using type, especially if down the line additional controls or features are associated with a type e.g. input number, date, password types, etc.

I think the reason why you haven’t is that the type attribute usually has some effect on UI display or behaviour. The proposal does not , AFAIK, specify any different UI, it only effects the accessibility semantics.

While there isn’t any different UI there are semantic differences between different types of navigation beyond only accessibility. A standard distinction could be useful for JS targetting and frameworks. Marking up of breadcrumbs is something that search engines already care about and schema.org has a spec for it which shows some demand for markup of this nature and as a developer I know I’d much rather just use <nav type="breadcrumbs">.

I agree this is a new use of type but type also has another usage already (specifying MIME types) and semantically still works. Rel could possibly be used describing how to navigation relates to the site but all other uses for rel are about external resources so I don’t think is as appropriate.

The epub:type vocabulary affects UI as well, especially for pagebreak and page-list. These terms have been added to DPUB-ARIA, and platforms that support EPUB are beginning to shift to role (in place of epub:type). This means that role will help generate page numbering for all users, not just those using AT.

We chose the term pagebreak instead of “page” because as pages are resized, the page marker should not move. Page numbering should be static even if the text reflows. This is crucial for citations and accessibility, especially in the scholarly world and for students.

Thanks for all the replies

Personally, I feel like I’d prefer type over role, for a few reasons:

• While role is built into HTML, all of its values are defined in ARIA, so to learn about this feature you’d have to go to two places.
• In my experience (your mileage may vary), devs only go to ARIA if they’re interested in A11y; either retro-fitting their existing markup if they designed without a11y in mind, or to add semantics that can’t be expressed by HTML, or as a polyfill for lack of support in browsers for new HTML features (the belts and braces (en-us: belts and suspenders) technique). I’d like this to be seen by devs that are oblivious of ARIA, or that are intimidated by ARIA as there are so many roles and properties and so much to learn outside of their comfort zone.
• It doesn’t solve the problem of clarifying what types of navigation meant to be nav elements. In many ways it’d make it more confusing as the valid types we come up with would be roles that remove the need for the nav element (or navigation role) in the first place
• Related to the above, the role attribute replaces the semantics of the element it is used on (div role=“breadcrumbs” or nav role=“breadcrumbs” would be the same thing), while I feel this is augmenting the semantics (breadcrumb navigation rather than just generic navigation). They’re still navigation.
• Type attribute is used in a number of places in HTML already (input is the classic example, but also button (submit button, menu button, etc.)
• Type attribute could be easier to discover through tooling. For example Visual Studio Intellisense suggests valid attributes and values for HTML. Roles are more generic to any element so it is harder here to suggest add role=“breadcrumbs” or whatever
• ARIA doesn’t add any behavior, just semantics for the a11y tree. There could be use cases for these beyond a11y, but perhaps some behavior could be suggested for each type (although we’d need to be careful not to break existing content, and it’d be easier to spec if just adding extra semantics)

+1 for type, for the reasons mentioned by dstorey… in particular <div role="navigation">, while not ideal, it is valid equivilant to <nav> today, so adding a @type attribute would work with both.

Overall I think this is a good idea, and I also think that type is preferred, and dstorey gives some excellent reasons as to why type is preferred over role.

+1 for type for reasons already stated

Great feedback @LJWatson.

I agree that toc and page should be different.

For “footer”, the spec suggests that the footer element alone is sufficient. That could be changed though if there is value. If it is, I wonder if it could be similar to header element where the position in the DOM (in this case inside the root most footer) gives it a default mapping of whatever<nav type="footer"> would map to, so you only need to explicitly add the type if it is not in the footer or you want it to have a different type.

“social” is interesting as they’re often a mix of some form of “follow me” or upvote/favourite, or post about this to your timeline/wall. Are they all a type of navigation? Or are they actions? I guess this is the button vs link (although it is kind of both as you’re performing an action like favouriting , but doing it by navigating to that site first)

“mobile” is tricky as ideally you want to have one navigation block that transforms its layout depending on viewport size (although it is often difficult to transform a typical horizontal menu into a hamburger button without changing the markup a bunch). If we did this it should be something more generic than mobile (compact?) as they apply on desktop at smaller sizes (Windows apps transform to hamburgers a bunch), and could apply to other form factors (TV, AR/VR, etc.)

(personal opinion, this does not necessarily represent the views of W3C, WAI or Knowbility)

I really like this idea, also not using the role makes sense to me – we should keep role for ARIA additions to HTML and not use it for HTML native features. Besides that, role defines what the element is, which in this case is navigation. Type says what type the element is: A navigation of the type toc, for example.

Other types:

• prevnext – for previous and next links without the possibility to jump to a certain page, also probably interesting for sliders/carousels
• global or external – when your site is part of a network of sites

I also wonder if we want to introduce a for attribute: I might have a pagination for a slider and a pagination of pages on the same page. Even with the type attribute I could not distinguish both without aria-labelling them. Having for would result in:

<section aria-label="Image Slider" id="slider"><nav for="slider" type="pagination">…</nav></section>

It’s very clear what the navigation does and from everywhere inside the slider users would be able to quickly get to the pagination navigation because they are linked. (Think of it as an HTML-native aria-controls.)