search

w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
60 stars 23 forks source link

How should labeledby calculation handle whitespace-only content? #233

Open dandclark opened 4 months ago

dandclark commented 4 months ago

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 https://github.com/web-platform-tests/wpt/pull/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 commented 1 week ago

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 commented 1 week ago

I don't like that there's no way to force no name. For example, if you have a title attribute on a

, 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 https://github.com/w3c/accname/issues/233#issuecomment-2223492897, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZRUCWSDS5ZYAH7HZYDZL25XPAVCNFSM6AAAAABEXCM77SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGQ4TEOBZG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

aleventhal commented 1 week ago

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

, 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 https://github.com/w3c/accname/issues/233#issuecomment-2223492897, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZRUCWSDS5ZYAH7HZYDZL25XPAVCNFSM6AAAAABEXCM77SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGQ4TEOBZG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

MelSumner commented 1 week ago

FWIW I think we're twisting ourselves up a little bit.

The purpose of recognizing white space in an accessible name or description was so that we didn't have run-on words.

If the whitespace to be added does not serve that purpose, why add it?

Then again, can we tell if it would prevent a run-on scenario?