Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add steps for shadow roots and slots #167

Merged
merged 18 commits into from
Feb 27, 2024
Merged

Add steps for shadow roots and slots #167

Changes from 8 commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
cf152ed
Add steps for shadow roots and slots
nolanlawson Sep 15, 2022
3007834
Update index.html
nolanlawson Sep 29, 2022
852dd64
Update index.html
nolanlawson Sep 29, 2022
8020dce
Update index.html
nolanlawson Sep 29, 2022
37d4048
Update index.html
nolanlawson Sep 29, 2022
fd225a3
Update index.html
nolanlawson Sep 29, 2022
afd6ea5
Update index.html
nolanlawson Sep 29, 2022
95782ce
add language about slot representing
nolanlawson Sep 29, 2022
442df9a
fix: fix roman numerals
nolanlawson Oct 20, 2022
8d17a28
fix: remove comment
nolanlawson Oct 21, 2022
51c6b09
chore: fix whitespace
nolanlawson Nov 17, 2022
f33d45d
Merge branch 'main' into shadow-dom
jnurthen Mar 23, 2023
ecf6cb4
Merge remote-tracking branch 'origin/main' into shadow-dom
nolanlawson May 26, 2023
9a625c8
Merge remote-tracking branch 'nolanlawson/shadow-dom' into shadow-dom
nolanlawson May 26, 2023
a9cfa2e
fix: revert whitespace changes
nolanlawson May 26, 2023
84a03a5
fix: update index.html
nolanlawson Jun 1, 2023
1d37077
fix: update index.html
nolanlawson Jun 1, 2023
493b13b
Merge branch 'main' into shadow-dom
jnurthen Feb 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 18 additions & 4 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -224,6 +224,8 @@ <h4>Terminology</h4>
<dd>The <abbr title="Document Object Model">DOM</abbr> [=nodes|node=] or [=element=] for which the text alternative is sought.</dd>
<dt>Current node</dt>
<dd>The <abbr title="Document Object Model">DOM</abbr> [=nodes|node=] currently traversed to compute the <code>root node</code>'s text equivalent. Initially, the <code>current node</code> is the <code>root node</code>, but at later stages is either some descendant of the <code>root node</code>, or another referenced node.</dd>
<dt>Rendered child nodes</dt>
<dd>The [=nodes=] that are rendered as child nodes of a given node when taking [=shadow root|shadow roots=] and [=slot|slots=] into consideration.</dd>
<dt>Flat string</dt>
<dd>A string of characters where all carriage returns, newlines, tabs, and form-feeds are replaced with a single space, and multiple spaces are reduced to a single space. The string contains only character data; it does not contain any markup. </dd>
<dt>Total accumulated text</dt>
Expand Down Expand Up @@ -394,11 +396,23 @@ <h4>Computation steps</h4>
<li>For <code>:after</code> pseudo elements, <a class="termref">User agents</a> MUST append <abbr title="Cascading Style Sheets">CSS</abbr> textual content, without a space, to the textual content of the <code>current node</code>. </li>
</ul>
</li>
<li id="step2F.iii">For each child node of the <code>current node</code>:
<li id="step2F.iii">
Determine the <code>rendered child nodes</code> of the <code>current node</code>:
<ol>
<li id="step2F.iii.a">Set the <code>current node</code> to the child node.</li>
<li id="step2F.iii.b">Compute the text alternative of the <code>current node</code> beginning with step 2. Set the <code>result</code> to that text alternative.</li>
<li id="step2F.iii.c">Append the <code>result</code> to the <code>accumulated text</code>. </li>
<li id="step2F.iii.a">If the <code>current node</code> has an attached [=shadow root=], set the <code>rendered child nodes</code> to be the child nodes of the [=shadow root=].</li>
<li id="step2F.iii.b">Otherwise, if the <code>current node</code> is a [=slot=] with [=slot/assigned nodes=], set the <code>rendered child nodes</code> to be the [=slot/assigned nodes=] of the <code>current node</code>.</li>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might well be missing something - this spec still really boggles my brain - but what excludes the <slot> itself from being processed? The Chromium bug you filed is the precise example of this. We'll process the label as an idref, start walking its descendants as a result of 2h, recurse into the div, recurse to the slot as one of the child nodes of the div starting at step 2, and end up using the aria-label on the slot in 2d.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention is to tweak the children-traversal part of the algorithm to traverse into slot assigned nodes rather than child nodes. The slot itself is not excluded from processing; you're correct.

Based on w3c/html-aam#440 it looks like this should be handled in the html-aam spec instead?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The slot itself is not excluded from processing; you're correct.

If I understand correctly, that means the Chromium bug isn't dealt with by this addition to the spec, correct? I'm not saying this isn't necessary, just clarifying for sure that it doesn't address the Chromium bug.

it looks like this should be handled in the html-aam spec instead?

This gets back to my comment about tree traversal. As I see it, it's less to do with the fact that a slot can't be named and more to do with the fact that the slot itself (but not its rendered children) should be skipped in the traversal in the first place. I realise this might sound like nitpicking, but I think it's important in understanding how browsers actually do this.

Copy link
Member Author

@nolanlawson nolanlawson Oct 21, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, that means the Chromium bug isn't dealt with by this addition to the spec, correct?

Correct, it's unrelated.

As I see it, it's less to do with the fact that a slot can't be named and more to do with the fact that the slot itself (but not its rendered children) should be skipped in the traversal in the first place.

That makes sense to me! I would ask @scottaohara if this is similar to other "HTML elements which do not support naming," or if <slot> is a special case?

To add another wrinkle: the default UA stylesheet for <slot> has display: contents, but this can be overridden by the web author. So I'm not sure of the "namelessness" of slots is due to their being slots, or due to display: contents.

Edit: apparently display: contents should not affect the accessibility tree, but today it does? So it may be irrelevant to the <slot> discussion.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh blah. You're right: it's probably the fact that it has display: contents that excludes it from the Firefox a11y tree. As your test case shows, it does get exposed with display: block (because block elements have some semantic value by virtue of being block). That means that <slot aria-label="foo"> probably would get exposed in Firefox except for this bug.

So it does look like we'll need some explicit provision that slots shouldn't be exposed. I'm not sure if them not having a name is enough. That said, this is a bit tricky because <slot style="display: block;" tabindex="0"> does become focusable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that makes sense! To identify this bug, we could try adding WPT tests that set display: block on the <slot>.

That said, this is a bit tricky because <slot style="display: block;" tabindex="0"> does become focusable.

Well, maybe <slot> should be an element that can support naming? Unless #173 (comment) is the last word on this.

Note that I don't have a strong opinion; I'm just trying to determine the correct behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case someone does <slot style="display: block;" tabindex="0">, we've gotten quite into the territory of author error correction.

If properly used, the slot element, along with elements like title, meta, template, etc... none of those should ever actually be exposed to a user and they should not be nameable. But, if you force these elements to be rendered by changing their CSS display property, then they essentially become 'generic' elements.

I think it makes sense to call out that if an author forces elements like these to be exposed to the a11y tree, then browsers should handle them like generics. But, again, I would stress this is correcting for author misuse and otherwise - if used properly - they cannot be named.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to call out that if an author forces elements like these to be exposed to the a11y tree, then browsers should handle them like generics.

@scottaohara Thanks for the feedback! Do you think this should be done in accname or html-aam? I'm wondering if it makes more sense to put it in html-aam (per w3c/html-aam#440), since in accname we're merely defining the tree traversal algorithm w.r.t <slot>s and their assigned nodes, not whether <slot>s can be named.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, i think this should be handled in html aam per the linked issue. i don't think accName should need to call this particular element out in any specific way. that's is what html aam can do.

<div><details>
<summary>Comment:</summary>
<p>A [=slot=] element represents its [=slot/assigned nodes=], if any, and its contents (child nodes) otherwise.</p>
nolanlawson marked this conversation as resolved.
Show resolved Hide resolved
</details></div>
<li id="step2F.iii.c">Otherwise, set the <code>rendered child nodes</code> to be the child nodes of the <code>current node</code>.</li>
</ol>
</li>
<li id="step2F.iiii">For each <code>rendered child node</code> of the <code>current node</code>:
nolanlawson marked this conversation as resolved.
Show resolved Hide resolved
<ol>
<li id="step2F.iiii.a">Set the <code>current node</code> to the <code>rendered child node</code>.</li>
<li id="step2F.iiii.b">Compute the text alternative of the <code>current node</code> beginning with step 2. Set the <code>result</code> to that text alternative.</li>
<li id="step2F.iiii.c">Append the <code>result</code> to the <code>accumulated text</code>. </li>
</ol>
</li>
<li id="step2F.iv">Return the <code>accumulated text</code> if it is not the empty string ("").</li>
Expand Down