Discussion: aside vs complementary

Note: This issue is a proxy for w3c/html-aam#86, but I want to bring the issue to the wider group and discuss how we want to proceed. If we decide to make this change, I can provide PRs for HTML-AAM and HTML-ARIA.

The ARIA definition of complementary says:

A landmark that is designed to be complementary to the main content at a similar level in the DOM hierarchy…

The HTML definition of aside says:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element… The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements...

Here's the thing: I don't think pull quotes should be landmarks. I don't think sidebars within an article should be landmarks, either.

I think the following points in the APG's guidance for complementary say it well:

complementary landmarks should be top level landmarks (e.g. not contained within any other landmarks).
If the complementary content is not related to the main content, a more general role should be assigned (e.g. region).

Since HTML aside is more permissive than ARIA complementary, and since aside maps directly to complementary without restriction, authors are defining landmarks that they didn't intend to be landmarks. Possibly lots of them.

Interestingly, axe-core flags a violation for an aside or complementary that is not at the top level. Of course, this means that authors who don't want any axe-core violations can't use asides in the "put 'em anywhere" way defined in the HTML spec... unless they specify some other role on the aside, like perhaps role="presentation" or role="note".

But that puts the onus on authors to know what's going on, understand ARIA, and come up with a work around. More likely, they would just delete any flagged asides and wonder why they misunderstood the HTML spec.

I think the axe-core rule should stay. I think it's a good rule. And I think we can help authors by refining the mapping for the aside element, which I believe would make this better for users of AT.

I propose that we restrict the mapping of aside so that it only maps to complementary if it's a top level landmark (i.e. scoped to the body element), similar to the language for header and footer in HTML-AAM and HTML-ARIA, except that instead of mapping to "No corresponding role" when it's not scoped to the body element, I think it probably makes more sense to map it to role="note". This gives AT the opportunity to announce when entering/leaving the note (some already do), or AT could provide a means for users to skip over the note if desired.

I think this would greatly clarify what asides are and what they are for, and it would reduce the number of frivolous complementary landmarks out there that had no business being landmarks in the first place.

I would prefer discussion on this topic happen over in the HTML AAM issue so that the decision on how to update (and i agree that something should be done) is handled in the spec that will be updated.

i'll add more thoughts there in response to your proposal.

@scottaohara

@scottaohara

I'm not really sure that it should be discussed exclusively over in HTML-AAM.
Agree that this is ultimately an HTML-AAM issue, and the HTML-ARIA spec is affected, too.

But the ARIA spec is also responsible for the confusion, due to it vaguely suggesting that complementary regions are at a "similar level in the DOM hierarchy to the main content". Whatever that means. This needs to be clarified one way or another.

Also, if we make any change at all, the APG will need to come up with guidance describing that change, because currently it also says, "complementary to the main content at a similar level in the DOM hierarchy".

All this to say I think that - for now - the discussion should happen in the full ARIA group, possibly in a Deep Dive with you & @stevefaulkner invited. :)

Here's the thing: I don't think pull quotes should be landmarks. I don't think sidebars within an article should be landmarks, either.

I agree on pull quotes. But sidebars (or similar) aren't as cut-and-dry. Given the increasingly convoluted layouts of many news/blog-type outlets, I'm not immediately in favour of any change which makes it more difficult for users to bypass the array of ads, newsletter forms, related content blocks and other callouts.

To my mind, all of these are semantically complementary to the surrounding content. That's what site designers are going for, at any rate, even if many readers just find them annoying and irrelevant. Likewise, I think note and region would be too generic; region in particular feels like it carries more weight and is more suited to a distinct section of functionality in its own right (e.g. a comments experience or the main article body).

To zoom in on the wording here, I think one of the key differences between the ARIA and HTML specs is that the latter mentions content surrounding an aside, whereas the former seems to be implying that content related to main should only ever come before or after it. As a user, I would be over the moon if websites followed the second pattern, letting me read the content in full and only then bombarding me with their engagement strategies. But in the wild it just doesn't happen:

On a relatively clean website without in-article callouts, it's perfectly feasible to have the content, a related-style block, the comments and then maybe even something else. In such a scenario, it makes sense to me that main would have several child blocks, and that at least one of them would be a complementary. But I could also see some people holding a view that the article content should be the main, and related/comments/etc. should be siblings of it with appropriate top-level roles. Personally I prefer the cleaner, hierarchical nature of the first approach.
On many websites though, as mentioned above, bits and pieces of non-article content are scattered throughout, making it impossible to only use complementary outside of main. Guaranteed that somebody would try a sort of resumption pattern, with multiple mains with complementaries interspersed, which of course you can't do.

So, in short, I disagree with:

complementary landmarks should be top level landmarks (e.g. not contained within any other landmarks).

... and:

I propose that we restrict the mapping of aside so that it only maps to complementary if it's a top level landmark (i.e. scoped to the body element)

I wouldn't necessarily be opposed to the proposal that the scope be limited to children of body and main, though. Off the top of my head, I can't think of a case where having a complementary nested inside main at the grandchild or deeper level would be a good idea. Likewise, complementaries inside headers, navs and footers feels off.

@carmacleod

@carmacleod, yes I understand your comment on it not being exclusively discussed in html aam. i can see an editorial update to the complementary landmark definition to clarify where the landmark may be expected - i.e., stop the confusion about it needing to be a sibling of the main landmark. ARIA and APG could well use that.

I just want to make sure the discussion around what mapping changes are necessary happen in the spec repo where that will be defined.

@sinabahram

From w3c/html-aam#86 (comment)

(from a long web a11y slack thread)

I'm sad that I didn't remember to look at the web-a11y slack when I was researching asides. There's a lot of good comments in that thread.

The reason I began researching was because in separate chats with @sinabahram and @mcking65 about landmarks in general, they both made unsolicited complaints about complementary landmarks. :)

Sina said:

for aside - people don't use it correctly - maybe take top 100 pages for whether aside is used correctly
aside has changed over the years regarding whether screen readers will read it out or not (it's configurable - all landmarks - whether you want them read out)

Matt said:

pretty much every complementary that I have come across, I would be happy if it was just a region

Also, @LJWatson's original draft of the landmarks section of the APG has this tip:

Tip: banner, main, complementary and contentinfo are all top level landmarks

So I took a look at some web sites to try to find asides in the wild:

https://github.com/ - 2 asides at the top level
https://www.amazon.com/ - 1 top level aside
https://www.bbc.com/ - 1 top level aside
https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/ - 1 top level aside with nav child
http://www.citypages.com/news - 1 aside within main - good example of nested aside that is a reasonable landmark
https://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/ - this page is intended to show correct use of landmarks. It has 1 aside marked up as a child of main, but the visual design clearly shows the aside as a top-level sibling of main... a perfect example of how confusing all of this is.
http://csszengarden.com/ - top level aside with 2 nav children

Here are some asides that are... weird. Most of these I wouldn't call complementary landmarks:

http://soup.io - 17 asides used to mark up name of person who posted link to article
http://www.umt.edu/ - aside within main, but it only contains 6 words, so not a very useful landmark
http://www.ymcdn.com/ - simple page with top level aside, but has an unnecessary aside in the footer

I also saw some that I would just call bugs:

http://louisville.edu/ - top level aside that should probably be a nav, completely missing main
http://www.hardened-php.net/ and http://minecraftm.com/ - top level aside, which is ok except that the aside has a bunch of nested asides
http://www.bom.gov.au/ and http://sbwire.com - top level aside, but completely missing main
http://lesscss.org/ - top level aside should be a nav (hmm, banner inside main)

@jscholes

I wouldn't necessarily be opposed to the proposal that the scope be limited to children of body and main, though. Off the top of my head, I can't think of a case where having a complementary nested inside main at the grandchild or deeper level would be a good idea. Likewise, complementaries inside headers, navs and footers feels off.

I am convinced, and I completely agree now that asides nested in main should be landmarks, too. You are not the only one to expect this - some folks on the aforementioned slack thread have this expectation as well, plus folks who gave feedback on the axe-core issue and w3c/html-aam#86 (comment).

@carmacleod

So I took a look at some web sites to try to find asides in the wild:

Thanks for putting this list together, @carmacleod. I want to dig into a few of them a bit further.

https://www.bbc.com/ - 1 top level aside

Arguably, this aside isn't necessary as it only wraps a nav. The nav on its own would be sufficient.

If we look at an article on the same website:

https://www.bbc.com/news/world-us-canada-55972619

There are four asides nested in main: "Top Stories", "Features", "Elsewhere on the BBC" and "Most Read", none of which complement the main content. So these would be ideal candidates for labelled regions. But the section right before "Top Stories", which is titled "More on this story", is exactly what I see as complementary content that works as a child of main. Granted, here it isn't marked up as a landmark of any kind.

http://soup.io - 17 asides used to mark up name of person who posted link to article

I agree, this is nonsensical. But would this fit the HTML spec description of "tangentially related" content either? I'm not sure I'd consider the author of a post to be tangentially related; there is a direct connection there. In other words, this doesn't feel like a description of where somebody is correctly following the HTML spec while creating a conflict with the ARIA one, it just feels wrong, period.

https://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/ - this page is intended to show correct use of landmarks. It has 1 aside marked up as a child of main, but the visual design clearly shows the aside as a top-level sibling of main... a perfect example of how confusing all of this is.

Could you expand on the visual design and how it differs from the hierarchy in the mark-up? Looking at the page with a screen reader, having the related aside be a child of main doesn't create confusion (for me personally), and I wouldn't question it if I hadn't been told that the visuals don't match.

http://csszengarden.com/ - top level aside with 2 nav children

Unlike the MDN sample, this is what I'd call confusing. The aside is after the footer, well, correction: after two footers, and wraps content that I simply don't understand the purpose of. Given its position after the second footer, I can only assume that there is some sort of connection between those two things, but nothing is labelled and I'm at a loss to what it might be.

Given that the aside is top-level though, nothing in this proposal would change the fact that this page is bewildering. On the contrary, I might find the relationships easier to understand if there was some nesting at play.

In summary, I think it's important to distinguish between cases demonstrating a disconnect between an HTML aside and an ARIA complementary role, versus websites with plain bad mark-up. Of the ones I've highlighted above, I find the MDN one the easiest to understand as a screen reader user, and don't really understand what benefit there would be on that page if either:

they moved the aside up and out of main; or
a screen reader didn't identify the related aside as having a complementary role just because it's nested in main.

Indeed, for point #2, it would decrease the navigability of the content IMHO.

For BBC.com, I agree that the aside that just wraps a nav should just be removed.
Also agree with your comments about the nonsense pages (17 asides that aren't asides, zengarden confusion, etc).

For the BBC article that you found: visually, the 4 asides are in a sidebar on the right, the article itself is displayed on the left, and the "More on this story" section is below the article, following a "Related Topics" section that would also qualify semantically as complementary.

This is so nuanced! I wouldn't have nested any of those asides in the main because they're visually separated in a sidebar with lots of whitespace between. However, I would have used asides because I think they're "tangentially related" (other stories and all that) so I think they match the HTML definition. But you're right - they don't really "complement" the main unless you really stretch the definition of "complement"... or stretch the definition of "this main" to be "a news story on bbc.com".

I guess I thought part of the goal of landmark regions was to help convey the visual structure of the page, at least to the point where that visual structure implied semantics. But maybe I need to change my thinking.

Apparently the aside element started out as <sidebar> and transitioned to "aside", with all of its tangential semantics (pun intended). I could see a case for having a separate sidebar element, as stated in this thought from that linked 2009 email thread:

I can understand the argument about how the content of a typical page's sidebar is tangentially related to the other content in the page. But it's clear that the use case of a pullout-type aside is conceptually different from that of a page sidebar, and for that reason, I think it might be worth reintroducing the <sidebar> element as a distinct sectioning element, and limiting the uses of <aside> to things like pullouts, footnotes and other non-sidebar uses.

Heh, if we call it a sidebar landmark, that would give AT users an opportunity to skip over a bunch of tangential cruft... 😄

https://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/
Could you expand on the visual design...

Banner, main, footer all have the same width. They are separated by a background grey color.
Visually, main is split into 2 columns: content starting with h2 "Article heading" in a wider column on the left, and content starting with "Related" in a somewhat narrower "sidebar" column on the right.
The 2 columns are separated by the same background grey that runs between the banner, main, and footer.
So visually, you would never guess that the sidebar was a child of the main - you would assume they were siblings.

@carmacleod

@carmacleod thanks for following up on this issue. I am one of the people who objected to the axe rule, in light of the conflict with the current HTML spec. In my posts I did use "pull quotes" as an example, because the HTML spec directly uses these as one of the examples that the aside element should be used for.

Personally, I don't mark up pull quotes with asides, but use presentational mark up, since they are the definition of presentational content. However, I do believe that "callouts" such as info boxes, appointments, numbered steps, etc. do qualify as complementary content. Some of these items do have their place in the flow of the document, as opposed to in a sidebar that follows the document. In that regard I very much subscribe to @jscholes point of view. Using a region would also work for these elements, but why use a generic element when there is a specific one?

If, as you say, the axe rule should remain, it would effectively limit the aside element for use as a sidebar only; which I guess would be fine if it was defined that way (and it seems it was at one point, based on your last post). With mobile first approaches, many modern websites don't actually use sidebars anymore, visually speaking, so that would make the aside element very limited in its application indeed (but then maybe that is the idea).

Ultimately, it is problematic for developers, if they are advised to use semantic markup, but get conflicting information. The end result is often a bowl of div salad, since that won't lead to any automated errors or warnings, and doesn't take up extra development or testing time.

The info is definitely conflicting at the moment. Not only in regards to the conflict with the html spec, but also on the ARIA practices page which in setp 2 of general principles of landmark design advises: "banner, main, complementary and contentinfo landmarks should be top level landmarks.", and in the very next bullet: "Landmark roles can be nested to identify parent/child relationships of the information being presented."

related HTML AAM PR w3c/html-aam#350

For the ARIA spec text, I think we could clearly call out that a complementary element can be a sibling or a child of the main content it is related to.

For ARIA Practices, I think we need to clarify that complementary could be a child of main. I don't see why something like the following would be a problem, outside of it not meeting the non-normative 'restriction' that complementary needs to be a top-level landmark:

<main>
  <article>...</article>
  <aside> ... </aside>  <!-- no html restrictions here, no overt normative ARIA restriction to indicate why this is bad  -->
  <article>...
     <aside>...</aside> <!-- HTML AAM update would make this not a landmark -->
  </article>
</main>

proposed rewording for the complementary landmark

Revised complementary definition re: DOM hierarchy

Revised complementary definition re: DOM hierarchy (#1779)

Navigation Menu

Repository navigation

Discussion: aside vs complementary #1396

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Discussion: aside vs complementary #1396

Description

Activity

scottaohara commented on Feb 7, 2021

carmacleod commented on Feb 7, 2021

jscholes commented on Feb 7, 2021

scottaohara commented on Feb 7, 2021

carmacleod commented on Feb 7, 2021

jscholes commented on Feb 8, 2021

carmacleod commented on Feb 8, 2021

kryp71c commented on Feb 17, 2021

scottaohara commented on Oct 29, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions