Can a complementary landmark be nested inside the main landmark?

[jha11y]

I'm seeking clarification if a complementary landmark can be nested in the main landmark.

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html says "complementary landmarks should be top level landmarks (e.g. not contained within any other landmarks).", but SHOULD is not MUST.

The spec is kind of ambiguous: "A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content."

[jha11y]

Moving over from https://github.com/w3c/aria/issues/1302 at request of @jongund

[mcking65]

@jha11y, good question.

Since the APG is not a spec, we generally avoid using 'should' and 'must'. We should clean up the language in this section. :)

While you may have observed that there are no normative authoring requirements in the spec, i.e., it does not say 'authors SHOULD' or 'authors MUST', it is clear that the intention is for complementary content to be separate from the main content. However, because there are no normative authoring requirements, authors are free to do what they think is best for users and validators will not flag errors. In other words, authors may make their own decisions.

The Authoring Practices Task Force aims to provide information that helps authors make decisions that are consistent with the intention of the ARIA specification and good for users. The intent of the specification is that complementary content complements main, which means it is not part of main.

Drawing on my own experience, I often find that authors often put a lot of content inside main that is really not part of the main content. I find it really annoying to jump to main and then have to read past things like breadcrumbs, or other content that is not really main content. If you had complementary content inside of main but at the end of main, that would be less problematic. If it is in the middle of main, then I wonder if there is a reading order problem.

I've encountered CMS with templates that are simply not flexible enough to define landmark regions appropriately. If you are stuck with something like that, it is often best to llean toward minimalism and only define the landmark regions that are clearly beneficial and avoid nesting and any region definitions that are of questionable value due to lack of clarity. The most useful are main and nav regions.

[jongund]

I like Janina comment in the same issue reported in the ARIA issue list. That screen readers tell you when you enter a region, but not if it is nested in another landmark or when you leave a landmark. So any nesting of landmarks, especially named landmarks, should be done cautiously and have a definite purpose of improving the experience of the screen reader user.

(https://github.com/w3c/aria/issues/1302)

[JAWS-test]

That screen readers tell you when you enter a region, but not if it is nested in another landmark or when you leave a landmark

This is not true in every case. For example, JAWS outputs the beginning and end of all regions when the page is read with the virtual cursor (unless the output of regions is generally disabled). Furthermore, nested regions are very well perceptible in the region overview of JAWS (as a tree structure).

Nevertheless, I agree that regions should be used sparingly and preferably not nested

[carmacleod]

@jongund I don't think @JaninaSajka's comment was about nesting?

[carmacleod]

Regarding nesting in general, just FYI, I've often seen site search and global nav landmarks nested within a banner landmark. Case in point, this github page that we are on right now has that structure. :)

This page also has a "Repository" nav and 4 form landmarks inside the main. Seems to me that the repo nav could have been outside the main, because it feels like the main part of this page is more about the current issue than the whole repo?

The 4 forms are "Assignees", "Projects", "Milestones", and "Linked issues" - i.e. the controls for setting and viewing the properties of the current issue. (Seems they forgot to put "Labels" in a form, too, for consistency). I guess it's a design decision whether those should be inside the main (because they truly pertain to the current issue), or if they would be better in a separate landmark on the side. If they were placed in a separate landmark on the side, I don't know whether or not a complimentary landmark would be appropriate in this case. I'm unclear on exactly what "remains meaningful when separated from the main content" means. Does it mean that it can be extracted from the page, syndicated, and used elsewhere? If so, then it is not an appropriate landmark for these forms because they have no meaning when separated from the current issue on the page. But if "remains meaningful when separated from the main content" means "they still make sense when they are right beside the main content", then complimentary (aka aside) does make sense (because after all, they are in a sidebar).

@mcking65 Do you have an opinion on the structural organization of this page?

[kryp71c]

@mcking65 thanks for the clarification, nevertheless the guidelines could more precise in regards to nesting:

In paragraph 4.2 General Principles of Landmark Design Step 2 states: "banner, main, complementary and contentinfo landmarks should be top level landmarks.", while the following bullet point claims "Landmark roles can be nested to identify parent/child relationships of the information being presented."

These are contradictory statements and only add to confuse instead of providing "information that helps authors make decisions".

The html spec for the aside element states that

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

but unlike the main element makes no claims about hierarchy. It would be difficult to use a pull quote outside of the main element. A pull quote may be a poor example if, as you state, a complementary element in the middle of the main document would make you question the reading order. Pull quotes appear at the beginning, middle, or end of a text.

Mozilla provides an example of an aside element inside of the main element as part of one of their accessibility documents (the second example under page layouts).

Seemingly, the guidelines are at odds with the intention of the html standards. The guidelines seem to be confusing enough to prompt deque to make it a rule in their accessibility validation tool (axe), so here is one validator that does flag nesting as an error.

[JAWS-test]

If the recommendations on complementary are to be based on the HTML specification on <aside> (which I think makes sense), then the following should be implemented:

• 4.2: complementary should be removed from the sentence "banner, main, complementary and contentinfo landmarks should be top level landmarks"
• 4.3.2: The sentence "complementary landmarks should be top level landmarks (e.g. not contained within any other landmarks)." should be replaced by: "complementary landmarks should be located as a sibling element or child element to the area to which they relate. This can be, for example, the main area of the page (main) or a subordinate page area (e.g. region)."

In addition, I would suggest adding to the sentence "Landmark roles can be nested to identify parent/child relationships of the information being presented." in 4.2 that multiple nesting is not recommended because the structure then becomes too complex and difficult to understand, and the screen reader output when entering the regions becomes too verbose.

[carmacleod]

Please see https://github.com/w3c/aria/issues/1396

[plweil]

For what it's worth, I don't think the HTML specification on <aside> necessarily contradicts the notion that it (along with the complementary role) ought to be a top level landmark. It is quite possible to use a pull quote or any of the other example content types outside of the main element. On its own, this does not seem to be sufficient reason for removing the mentioning of hierarchy from the specification and guidelines. But the HTML specification on <aside> and the specification on complementary ought to be brought into alignment one way or the other, particularly regarding hierarchy and nesting, because, as @kryp71c notes, they seem to be at odds with each other.