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