-
Notifications
You must be signed in to change notification settings - Fork 22
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.
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
Trim whitespace from computed accessible name/description #95
Comments
This matches the behaviour implemented by browsers. Filed w3c/accname#95 PiperOrigin-RevId: 344223264
This matches the behaviour implemented by browsers. Filed w3c/accname#95 PiperOrigin-RevId: 344223264
This matches the behaviour implemented by browsers. Filed w3c/accname#95 PiperOrigin-RevId: 344223264
This matches the behaviour implemented by browsers. Filed w3c/accname#95 PiperOrigin-RevId: 344223264
This matches the behaviour implemented by browsers. Filed w3c/accname#95 PiperOrigin-RevId: 344377895
From 2021/06/03 meeting: 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 |
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) |
Agenda+ since this is coming up in the context of the Interop Accessibility Focus Area |
@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. |
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. |
Discussed in https://www.w3.org/2024/05/09-aria-minutes.html#t08 |
@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? |
@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? |
Reading here, Computation Step 2D:
"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. |
@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. |
Thanks @MelSumner, let's find a time for the deep dive during next weeks meeting. |
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
The text was updated successfully, but these errors were encountered: