Trim whitespace from computed accessible name/description

[AlexLloyd0]

Should whitespace be trimmed from the returned accessible name or description? e.g.

<button aria-label=" Hello world ">Hi</button>

My reading of the spec is that the accessible name should be " Hello world ", but browsers expose it as "Hello world", which is more logical to me. Possibly related to #16

[jnurthen]

From 2021/06/03 meeting:

msumner: thinks we should trim whitespace, there are quirks where not doing that breaks stuff. In FF spaces in options have caused an issue jamesn: do we mean at the end of the calculation or during it? msumner: what to implementers think? sarah_higley: would advocate for at the end jcraig: there was some discussion about collapsing multiple whitespace.. is this trimming at the end or ANY whitespace? jcraig: we need to be careful about inadvertently adding whitespace that the author did not intend joanie: thinks the example of starting and ending with a space is sub-optimal authoring, but we should not trim msumner: the spaces may be unintentional, e.g. a side-effect of a CMS jamesn: there are 9 open acc name whitespace issues, this would be the 10th msumner: will look at this set of issues and categorize them

[joanmarie]

joanie: thinks the example of starting and ending with a space is sub-optimal authoring, but we should not trim

To be clear: Joanie thinks other trimming is good (e.g. at the end of calculation, and when it is NOT whitespace intentionally added by the author like in the opening report)

[cookiecrook]

Agenda+ since this is coming up in the context of the Interop Accessibility Focus Area

[cookiecrook]

@w3c/aria-editors please add new milestone for 2024... Need to resolve this for Interop 2024 so we don't have to pull out the WPT tests from the Accessibility Focus Area.

[cookiecrook]

FWIW, we did remove/change the nbsp tests in WPT, because the ARIA spec resolved on ASCII whitespace, which does not include non-breaking space.

[spectranaut]

Discussed in https://www.w3.org/2024/05/09-aria-minutes.html#t08 Decision to deep dive all accname whitespace issues after @MelSumner does a review/categorizing of them

[spectranaut]

@MelSumner, are you coming to TPAC, either remotely or in person? Would you be interesting having an agenda item at TPAC for these whitespace issues?

[MelSumner]

@spectranaut I am not able to attend due to previous commitments, but I am actively working on the issue.

I could possibly do a virtual attendance on the Wednesday during TPAC if there's room on the agenda and folks will be around.

If not, then first deep dive after TPAC, if that works?

[MelSumner]

Reading here, Computation Step 2D:

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:

"nor, when trimmed of whitespace" seems kind of specific IMO. WDYT?

For aria-labelledby and aria-describedby, they can point to multiple id attributes, so probably shouldn't trim whitespace inside of those attribute values.

However, there's a whole other conversation about what to do with different types of whitespace in the elements those id attribute values point to, and we're dealing with those in multiple separate issues.

[MelSumner]

@spectranaut we're ready to do a deep dive for this, just need a week or two advance notice for the date.

@accdc and I have met and discussed the whitespace issues in accname and we have recommendations to present and items to discuss with the group.

[spectranaut]

Thanks @MelSumner, let's find a time for the deep dive during next weeks meeting.