<header> that is inserted into an <article> via a <slot> is marked as a landmark
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: elliot.nahman, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
350.96 KB,
image/png
|
Details |
Screen Shot 2022-08-11 at 9.22.32 AM.png
Steps to reproduce:
(1) Create a web component containing an <article> tag and a <slot> within the <article> tag.
(2) Insert a <header> tag in the light DOM of your web component
(3) View the accessibility tree and note that the header is marked as a landmark.
See my CodePen for an example: https://codepen.io/nonmetalhail/full/zYWamwv
Actual results:
The <header> is marked as a landmark as if it were not a descendent of an <article> tag.
Expected results:
The expected result is that the <header> would not be a landmark. It should be a "Section" just like when a <header> is a descendent of an <article> tag.
The CodePen example shows a plain HTML <article> with a <header> vs a web component where the <header> is in the light DOM being slotted into an <article> element so you can easily view the difference between the two.
Per https://www.w3.org/TR/html-aria/#docconformance
Header: If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner. Otherwise no corresponding role
So although the <header> being in the light DOM is not strictly speaking a descendent of the <article> tag, the intent is that it should be treated that way. Also, the accessibility tree marks it as a descendent, yet still provides the landmark.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Implementation note: Changing both instances of GetParent to GetFlattenedTreeParent in this code might be sufficient to fix this.
That said, I think the spec ideally needs to be clarified here if this really is the intent. "Descendant" in the context of DOM elements could reasonably be interpreted as meaning DOM descendant, as opposed to a11y tree descendant. Also, how should this work with respect to aria-owns, which also changes the "descendant" relationship?
Description
•