Suggest <aside> should map to complementary with restrictions

[stevefaulkner]

Like the header and footer and section elements, the aside element can be used liberally within a HTML document. This liberal use can lead to the semantics of the element becoming noise to aural UI users. What we did for the header/footer elements is to restrict the expression of the role semantics based on their nesting within other significant elements in the DOM. For the section element we restricted its expression based on the presence of an accessible name. I suggest we should do the same/similar for the aside element.
grep of aside usage - '<aside|' in *.txt: 9648 matches in 1376 files. 25221 files searched.

note: The data is derived from webdevdata.org latest dump (2016)

Some examples from above of pages with high usage up to 100+
The pages have been saved with their aside elements indicated visually:

• Bola.com
• efectococuyo.com
• Grafica.info.com
• Infirmiers.com
• pz-news.de
• splitsider.com

/cc @cookiecrook @asurkov @w3c/kiss

[LJWatson]

It would be interesting to know how many of the 1376 files contain just one or two <aside> elements. The average per file (based on your grep) is seven <aside> elements per file.

It's likely that the examples you noted significantly skew that average, giving rise to the possibility that most files use the <aside> element in reasonable quantities/ways.

Unlike the <section> element, an <aside> element does convey useful semantic information to screen reader users. The risk of requiring an accessible name in order to solve the outlier problem, is that we lose useful semantic information when the <aside> element is used reasonably/appropriately.

[jameswillweb]

I'm fully aware that I might be wrong but doesn't complementary relate only to the main content? Since an aside can belong to nested elements as well wouldn't this give a false connection between nested asides that use headings and the main content?

[mcking65]

I have similar concerns to @LJWatson.

In my experience, I have not encountered an overabundance of aside elements; it is nothing like the section problem we once had.

It may be best to continue addressing this in the authoring realm rather than with a change to mappings.

[stevefaulkner]

@LJWatson

It would be interesting to know how many of the 1376 files contain just one or two <aside> elements. The average per file (based on your grep) is seven <aside> elements per file.

Here are some numbers:

Of 8369 pages found using the aside element.

• 9.5% of pages with aside elements contain 10 or more aside elements
• 20% of pages with aside elements contain 5 or more aside elements

lots more detail: aside element usage in the wild

[jasonkiss]

Conversely, 76.8% have 3 or less instances of the aside element :-)

Either way, as @jameswillweb suggests, the complementary role is related to "the main content at a similar level in the DOM hierarchy", whereas aside is for content "tangentially related to the content of the parenting sectioning content".

So if the mapping of aside to complementary is to be restricted, it should be done in a way similar to what we did for header and footer elements. But since an aside element scoped to the main element is probably intended as a complementary landmark, I'd suggest the distinction should be something as follows:

• aside scoped to the body or main elements is mapped as complementary
• aside scoped to any sectioning content element, or a sectioning root element other than body, is mapped as a generic group (Note that UIA or AX may want to provide a more specific localized control type or AXRoleDescription, respectively, such as "aside")

[stevefaulkner]

will update spec and file bugs on browsers

[csnover]

Since the HTML spec describes several uses of <aside> which don’t scream “page landmark”, I doubt that web authors have a mental model of <aside> that matches the current HTML-AAM behaviour. I know I didn’t—I only discovered <aside>’s current behaviour when I went to test some software I’d been writing and found tons of unlabelled complementary landmarks in the AT.

My expectation as an author would be that a non-<body>-scoped <aside> element would have an implicit note role, per its description in the ARIA spec.

I don’t know what the element usage data looks like today and the links in this thread to data from 2017 have rotted, but I do know that any site using @discourse (which includes the WICG) has unusable landmark navigation right now in part because that software wraps every quote in an <aside>.

@stevefaulkner, are you still planning to make this change? Is there any timeline?

[scottaohara]

picking up where this issue left off, this recent axe-core issue (from a long web a11y slack thread), and today's ARIA #1396

I am largely in favor of Jason's proposal from above...

I'd suggest the distinction should be something as follows:

• aside scoped to the body or main elements is mapped as complementary
• aside scoped to any sectioning content element, or a sectioning root element other than body, is mapped as a generic group (Note that UIA or AX may want to provide a more specific localized control type or AXRoleDescription, respectively, such as "aside")

caveats being that I could well see aside also mapping to complementary if an author decides to give it an accessible name. So really bullet two there being that it's treated as section and form are, in regards to needing to be named to have their landmark role exposed... but the first bullet serving to not completely wipe complementary landmarks.

Regarding the thoughts about mapping aside to role=note, I am not convinced this is a good idea. Per HTML's definition of the aside element:

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...

too many things mentioned in there that would not be appropriate for a role=note, defined as

A section whose content is parenthetic or ancillary to the main content of the resource.

while aside would no longer be unnecessarily polluting the number of landmarks on a page with a role=note mapping, it could well then create an abundance of "notes" containing very non-noteworthy content.

[csnover]

That web a11y Slack link requires a login so I can’t review that discussion for comment.

I will be satisfied with any change here to get non-body, non-main aside out of the landmarks list. If that means generic groups instead because there’s no strong consensus on the purpose of role=note after eleven years, I’m not going to argue against it. Just do it! :-)

[scottaohara]

yeh, sorry @csnover. the slack link is only useful if you can get to it...but figured that was better than nothing.

i may try to recreate it in a 49 post response thread... but essentially the gist was confusion over when/where an aside could be used because the following is valid HTML, but the axe automated checker was failing it

<main>
  <article></article>
  <aside></aside>
</main>

[carmacleod]

Regarding the thoughts about mapping aside to role=note, I am not convinced this is a good idea.

I guess we need to discuss whether asides not in the scope of body or main should have "No corresponding role", or role="note", or role="group". It may come down to quibbling over the difference between "complementary", "tangential" and "parenthetic or ancillary". 😂

[scottaohara]

well if we're using the HTML spec as the reference point as to why aside shouldn't always map to complementary, then yes, same applies to a note. a side navigation isn't a "note", nor is an advertisement. arguably a pull quote is....if not really just a blockquote...but eh....

[carmacleod]

a side navigation isn't a "note", nor is an advertisement. arguably a pull quote is....if not really just a blockquote...

Good points, all.

role="group" then? For non-body-scope, non-main-scope asides? A touch on the useless side, but better than pull quotes as landmarks. Then I guess it would be up to the APG to suggest alternative roles...

[scottaohara]

i recall matt king being none too happy with an abundance of "groups" being announced in some past discussion, though i don't recall the specifics of that discussion. i tend to agree with him on the sentiment though. Also, role=group isn't typically (ever? would need to re-test) announced without also having an accessible name.

as far as i'm concerned, i don't see why an aside needs to be announced as anything special at all if it's filling one of the not-special-at-all roles that HTML would have it play (e.g., advertisement or pull quote which, using modern article narratives, is just a repeat of content that has been previously said in the primay article content).

and if it does need to have special semantics exposed to the a11y tree... well then use it as a named complementary. or use an actual nav. or use a blockquote ( hey ARIA 1.2 has a mapping for that now! :) )

edit: also just noticed that when you quoted me you left out the "but eh...". that was arguably the most important part of that response ;)

[jongund]

I would advocate only mapping aside to complementary when it is a top level landmark like main, header and footer elements.

I don't think we need the aside element to identify sub-sections of the main landmark.
Sub-sections of the main element are better served by a more general rule that subsections of top-level landmarks (e.g. banner, main, complementary and footer) use named region landmarks.

I don't think we should map aside to a group role by default. I think we need more author intent for accessibility to map to a group role. We seem to want to assume most authors know something about accessibility and HTML markup, and most don't. so let's not help them to much in doing the wrong thing.

For landmarks the purpose is to support efficient keyboard navigation and identification of major sections of content, similar to how a good visual design helps people identify the functional grouping of information in a graphical rendering. If there are two many or redundant landmarks they become less useful and often time confusing useless.

In human factors research there is the magical number 7 that seems to be about the optimal number of things for people to deal with in a list, so ideally a typical page would have 7 or less landmarks in a list for people to easily use them.

[scottaohara]

i'm actually not in agreement that there can't be complementary content within a main. There can be multiple articles or sections of the main content that may have tangentially related content that is still part of the "primary" content of the page, but would be odd to pull out of the main just so we could make complementary a strictly main-adjacent landmark. which is not what the ARIA spec says:

A landmark that is designed to be complementary to the main content at a similar level in the DOM hierarchy, but remaining meaningful when separated from the main content.

Because if it was meant to be only tangential to the main content/landmark, then it would have referenced the role, instead of using "main" as static text.

Additionally, I'd personally rather authors markup more complementary content, rather than having to use generic regions in their place. Use of region should be very limited.

@carmacleod @stevefaulkner I think we should go ahead with the idea that <aside> maps to complementary when:

• given an accessible name
• not a child of Sectioning content (article, aside, nav, section)
• not a child of sectioning roots, aside from body (so not: blockquote, details, dialog, fieldset, figure, td)

[carmacleod]

@scottaohara Agreed. Child of main, sib of main, or aria-label[ledby], and (poof!) it's a landmark.

[Aside <- 😄 : Have never been a fan of using aria-label[ledby] to change the role of an html element, but it's a necessary evil.
I think HTML should provide a way to label/define landmark elements. Some day, I'm going to push for that. But not today.]

[jongund]

I think if the aside element is a child of the main element it should be mapped to the region role, and then it will only be a landmark if it has an accessible name. If the aside element has no parent landmark role, it can be mapped to the complementary role (which everyone agrees). To make landmarks useful to assistive technology user, we need to make creating landmarks more intentional on the part of the author. Otherwise the list of landmarks is polluted with random regions of content based on the whims of the underlying HTML markup used to create the page.

[carmacleod]

@jongund I think that would be too complicated, and authors would get confused. Already, a lot of authors use aside within main, and they expect it to be a complementary landmark. They reason that if it's about the main content, it should be inside the main. I have been convinced that that's ok. Of course, "beside" main is ok, too, i.e. same level as main; sibling of main.

To make landmarks useful to assistive technology user, we need to make creating landmarks more intentional on the part of the author.

I completely agree, and I think HTML needs to take some responsibility for this. Something really obvious, like a boolean landmark attribute that authors can't possibly misunderstand. 😄 (then we just need to figure out the labelling problem 😳 ).

For now, though, I think Scott's solution to the problem is the best we have. I think it will reduce noise significantly, yet still allow authors to create complementary landmarks with a label if necessary.

[jongund]

@carmacleod
I think that if the aside element is a child of main landmark region it at least needs an accessible name to identify it as a complementary landmark so the user knows why it is different than the main content. It is important that the user has the information on why the author decided it was worthy of being a commentary region landmark when contained within the main content.