Open cookiecrook opened 1 year ago
I'm confused, I thought years ago we specified that inline elements would be treated as they are rendered visually with no whitespace.
This matches my test using your code example at: https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html
When was camel-cased specified to be broken out with whitespace in the algorithm?
ARIA WG discussed this morning...
Though there has been discussion of changing the AccName spec to not force this extra whitespace for inline elements, no change has landed in the spec so far. AccName still requires this extra space. (See a variety of discussions and proposals in the whitespace project)
WebKit is in line with the spec (forcing the extra space behavior as described in OP), but Gecko and Chromium appear to have updated to remove the extra space (for inline element), anticipating the spec change in favor of a better user experience despite being against the spec. Though WebKit is the only one to get the inline-block
test right.
I'm going to commit the WPT PR with the tests, after updating the first to be inline with the new intention, rather than the spec. And I'll file the bug for WebKit to align with the others, despite the spec being out of date.
FYI @twilco
Agree that we need to ensure AccName is aligned with common sense expectation that inline elements don't require the insertion of additional whitespace.
I'm reopening because I think this was closed accidentally without a necessary AccName change. (There was a WPT change though.)
I added the following test case in this WPT PR.
The Rendered content is camel-cased
ThisIsBroken
but AccName requires it be exposed to Accessibility asT hisI sBro ken
…The test case is admittedly contrived, but is the ARIA Working Group sure it wants to force whitespace-joiners in all element scenarios, even when the author has removed inter-element whitespace between inline elements? If the web dev needs to style a substring of a word, there is no way for them to remove the extra spaces forced on accessibility users by the algorithm.
FWIW, the AccName algorithm requires the OPPOSITE for pseudo-elements, where joining without space is mandatory, but also seems somewhat arbitrary IMO. I vaguely recall the group said,
...and I understand that, but then why is it only for pseudo elements?
[Update: Intention is to align with the pseudo-element behavior, but no changes have landed in the AccName spec yet. See comments below.]