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?

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