Closed khiga8 closed 2 months ago
See below for some relevant references to specifications.
I've been known to get muddled between these specifications but my understanding is that:
aside
HTML element will be exposed by user agents to assistive technologies as one of two roles depending on it's scope:
complementary
if scoped to the body
or a main
element, or if scoped to sectioning content (aka scoped to a header
or footer
element) and it has an accessible name.generic
if scoped to sectioning content (aka scoped to a header
or footer
element) and it does not have an accessible name.aside
HTML element has an implicit complementary
role.These don't appear to be quite aligned.
Assuming user agents are actually conforming to the HTML-AAM specification in how they expose the aside
HTML element (and that this is the desired behaviour), it feels like HTML-ARIA needs an update to explain that the implicit role for the aside
HTML element can also be generic
depending on the scope (indeed the implicit ARIA semantics are stated to be defined in HTML AAM for this section of HTML ARIA).
There appears to be an open issue tracking this in the HTML ARIA repo already, so we can take the HTML AAM version of the truth reasonably confidently.
So afaik this project is documenting the dual element role mappings somewhat correctly. There is perhaps room for improvement as it appears to be missing the constraints for the scoped to the body or main element
variation of aside
being given a role of complementary
.
See also:
This specification defines the authoring rules (author conformance requirements) for the use of Accessible Rich Internet Applications (WAI-ARIA) 1.2 and Digital Publishing WAI-ARIA Module 1.0 attributes on [HTML] elements.
The following table provides normative per-element document conformance requirements for the use of ARIA markup in HTML documents. Additionally, it identifies the implicit ARIA semantics that apply to HTML elements. The implicit ARIA semantics of these elements are defined in HTML AAM.
HTML element | Implicit ARIA semantics (explicitly assigning these in markup is NOT RECOMMENDED) | ARIA role, state and property allowances |
---|---|---|
aside | role=complementary | Roles: feed, none, note, presentation, region or search. (complementary is also allowed, but NOT RECOMMENDED.) DPub Roles: doc-dedication, doc-example, doc-footnote, doc-glossary, doc-pullquote or doc-tip Global aria-* attributes and any aria-* attributes applicable to the allowed roles. |
REF: https://www.w3.org/TR/html-aria/#docconformance
HTML Accessibility API Mappings (HTML-AAM) defines how user agents map HTML [HTML] elements and attributes to platform accessibility application programming interfaces (APIs).
HTML Specification | aside (scoped to the body or main element) |
---|---|
[wai-aria-1.2] | complementary role |
REF: https://www.w3.org/TR/html-aam-1.0/#el-aside-ancestorbodymain
HTML Specification | aside (scoped to a sectioning content element) |
---|---|
[wai-aria-1.2] | complementary role if the aside element has an accessible name. Otherwise, generic role. |
Hi! I'm looking at tests/src/elementRoleMap-test.js, and I noticed that the entries for
elementRoleMaps
includes both:and later
These seem to conflict with each other.
Should
[{"name": "aside"}, ["complementary"]]
be removed? I think this is coming from complementaryRole.js.Tangentially, which document should I be looking at as the source of truth? I saw both https://www.w3.org/TR/html-aam-1.0/ and https://www.w3.org/TR/wai-aria-1.2/#roles referenced, and wasn't sure which one. Thank you!