Giters

w3c / accname

Accessible Name and Description Computation

Home Page:https://w3c.github.io/accname/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AccName forces whitespace joiners between all inline element scenarios

cookiecrook opened this issue · comments

commented

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 as T hisI sBro ken…

<button data-expectedlabel="T hisI sBro ken" data-testname="button name from content for each child (no space, inline)" class="ex">
  <span>T</span><span>hisI</span><span>sBro</span><span>ken</span>
</button>

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,

~"Well, at least joining without space gives authors a way to choose space, by adding extra whitespace to the CSS content value…"

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

commented

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?

commented

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.

commented

Agree that we need to ensure AccName is aligned with common sense expectation that inline elements don't require the insertion of additional whitespace.

commented

I'm reopening because I think this was closed accidentally without a necessary AccName change. (There was a WPT change though.)