How should labeledby calculation handle whitespace-only content?

[dandclark]

I'm looking at the test case "button's hidden referenced name (visibility:hidden) with hidden aria-labelledby traversal falls back to aria-label" in the WPT accname/name/comp_label.html.

<button aria-labelledby="span4" aria-label="foo" data-expectedlabel="foo" data-testname="button's hidden referenced name (visibility:hidden) with hidden aria-labelledby traversal falls back to aria-label" class="ex">
  <span id="span4">
    <span id="span5" style="visibility:hidden;">label</span>
  </span>
  x
</button>

One problem is that the span4 element ID is duplicated from the previous test; I'm fixing that in web-platform-tests/wpt#45117.

In Chromium, the test still fails because Blink includes the whitespace under span4 as span4's a contribution to the LabeledBy Recursion in step 2B LabeledBy. So we end up using that whitespace as the computed name, instead of falling back to the aria-label, and the test fails.

If I delete the whitespace under span4 then the test passes.

The spec language doesn't say anything here about not counting whitespace:

• i. Set the accumulated text to the empty string.
• ii. For each IDREF:
  • a. Set the current node to the node referenced by the IDREF.
  • b. LabelledBy Recursion: Compute the text alternative of the current node beginning with the overall Computation step. Set the result to that text alternative.
  • c. Append a space character and the result to the accumulated text.
• iii. Return the accumulated text if it is not the empty string ("").

So per the spec, Chromium's behavior seems to be correct and the test incorrect, but I don't think that's the intent. Should the spec have a step to strip whitespace from the accumulated text in step iii before deciding whether not to return it?

[MelSumner]

If adding a step to strip the whitespace from the accumulated text so that it will correctly fall back to the aria-label, then we should add it.

Do we think this is the case?

ETA: revisiting this on 3/4/2025 and careful re-reading of the specification informs me that my initial response was incorrect per spec.

[aleventhal]

I don't like that there's no way to force no name. For example, if you have a title attribute on a <div>, and have that info in another way, you might not want it to be converted to a name. I had an example of this the other day, where the title was only there because css text-ellipsis sometimes truncated things visibly (but not in the a11y tree).

…

On Thu, Jul 11, 2024 at 1:25 PM Melanie Sumner ***@***.***> wrote: If adding a step to strip the whitespace from the accumulated text so that it will correctly fall back to the aria-label, then we should add it. Do we think this is the case? — Reply to this email directly, view it on GitHub <#233 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZRUCWSDS5ZYAH7HZYDZL25XPAVCNFSM6AAAAABEXCM77SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGQ4TEOBZG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aleventhal]

IOW, IMO, aria-label="", aria-label=" " or aria-labelledby pointing to empty/whitespace text should all cause there to be no name on something. There can be reasons to do that. On Thu, Jul 11, 2024 at 1:38 PM Aaron Leventhal ***@***.***> wrote:

…

I don't like that there's no way to force no name. For example, if you have a title attribute on a <div>, and have that info in another way, you might not want it to be converted to a name. I had an example of this the other day, where the title was only there because css text-ellipsis sometimes truncated things visibly (but not in the a11y tree). On Thu, Jul 11, 2024 at 1:25 PM Melanie Sumner ***@***.***> wrote: > If adding a step to strip the whitespace from the accumulated text so > that it will correctly fall back to the aria-label, then we should add it. > > Do we think this is the case? > > — > Reply to this email directly, view it on GitHub > <#233 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKQAZRUCWSDS5ZYAH7HZYDZL25XPAVCNFSM6AAAAABEXCM77SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGQ4TEOBZG4> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[MelSumner]

I wonder if, because the whitespace is the result of formatted code (linebreaks and tabs/spaces), that kind of whitespace should be removed.

Formatting whitespace (is there an existing formal/more correct name?) shouldn't add semantic meaning to anything.

(FWIW, I've run into issues before just with HTML where code-formatting whitespace issues can make things not render, or not render correctly, in the browser, and it's super frustrating).

Also, aria-label already references trimming whitespace (to respond to @aleventhal comment):

AriaLabel: Otherwise, if the current node has an aria-label attribute whose value is not undefined, not the empty string, nor, when trimmed of whitespace, is not the empty string:

[aleventhal]

IMO Chromium is correct and should not be failing a test here.

The browser engine is what decides which whitespace from the source should be rendered. The a11y implementation faithfully represents what's rendered.

You can see this if you change the button to a <div style="display:inline-block" contenteditable> (the button is inline-block by default in the user agent style sheet). Because a space shows up there, it's clear that representing the space is correct.

[MelSumner]

Coming back around to this to see if I can get this resolved finally.

If I delete the whitespace under span4 then the test passes.

My consternation here is that I can't seem to replicate this in the browser.

Here's a CodePen, where I've formatted the code differently to see if I get different accessible names: https://codepen.io/melsumner/pen/pvodxrz/01e53d2abe3d096f507a23cbf31d5e85

In each case, the accessible name is the aria-label value in both Chrome and Safari.

1. I am not sure how we are supposed to discover the correct answer to these kinds of questions if we can't replicate the behavior.
2. I think the tests should reflect browser conditions since those are user conditions(?)

Per the current spec, the aria-label value should be the accname in the scenario you've described (at face value, anyway). I can't really make any suggestions about whitespace issues in tests if I can't replicate it in any browser.

[MelSumner]

@aleventhal

I don't like that there's no way to force no name.

That seems super unhelpful for users BUT there is a way, here's a repro: https://codepen.io/melsumner/pen/yyLPRrO/8ab9977f13d91632b99a458d99dee2a2

If you use the SPACEBAR key to insert a space into the span element, both Chrome and Safari seem to count that as not-existing and fallback to the aria-label value. However, if you use the HTML entity   that returns a blank label for both Chrome and Safari.

I tested this some more by putting text in to the visibility hidden spans. In both cases, if text was there, the HTML entity and the SPACEBAR space both provide a space: https://codepen.io/melsumner/pen/YPzEJoO/fd985b58b5636e86cac29a3e69299334

So the way to do it, if you wanted to force no name, would be to use the HTML entity  .

[MelSumner]

@dandclark working through guidance:

• The tests should reflect what the browser will render.
• SPACEBAR Space ( , U+0020): This is a regular space character. Browsers may collapse multiple consecutive spaces into a single space and may break lines at these spaces when wrapping text. Since this is already defined in HTML spec in multiple places, I don't think AccName should re-define it.
• Non-Breaking Space ( , U+00A0): This space prevents automatic line breaks at its position. It ensures that adjacent words or characters remain on the same line. If this kind of space is used, then it should not collapse.

I ran a bunch of different examples and things are working as I expect. Here are the examples:

<!--accname should be value of `aria-labelledby`-->
<button aria-labelledby="span4" aria-label="foo">
  <span id="span4" style="visibility:hidden">
    <span id="span5" style="visibility:hidden;">label</span>
  </span>
  x
</button>

<!-- accName should be value of `aria-label`-->
<button aria-labelledby="span4_1" aria-label="bar">
  <span id="span4_1">
    <span id="span5_1" style="visibility:hidden;">label</span>
  </span>
  x
</button>

<!-- accName is value of `aria-label`-->
<button aria-labelledby="span4_2" aria-label="baz">
  <span id="span4_2"> </span>
  x
</button>

<!-- accName is value of `aria-labelledby`-->
<button aria-labelledby="span4_3" aria-label="baz">
  <span id="span4_3">&nbsp;</span>
  x
</button>

<!-- accName is value of `aria-labelledby`-->
<button aria-labelledby="span4_4" aria-label="baz">
  <span id="span4_4" style="visibility:hidden">Mel S</span>
  x
</button>

<!-- accName is value of `aria-labelledby`-->
<button aria-labelledby="span4_4" aria-label="baz">
  <span id="span4_4" style="visibility:hidden">Mel&nbsp;S</span>
  x
</button>

Please let me know if this resolves your issue or if you require further clarification. Thank you!