AccName forces whitespace joiners between all inline element scenarios #205
Comments
cookiecrook
changed the title
|
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: 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 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. |
While not formalized in the AccName spec yet, there are discussions about adding white-space around inline-block elements. - w3c/accname#205 - w3c/accname#15 - w3c/accname#3 This change will make Chromium add whitespace around inline-block, inline-grid, inline-table, and inline-flex elements when computing Name from Content. This will let us pass the WPT tests that are in progress of being written: web-platform-tests/wpt#42354 Notes: - The WPT tests only mention inline-block, and there is no mention of the other inline-* properties yet. I think it's OK that this patch adds whitespace around other inline-* display properties (probably moreso than inline-block) because those properties define special formatting rules for their children, but let me know if you disagree and I can special-case this logic for inline-block. - It seems that <math> elements have an AtomicInline display type, similar to the other inline-* display types. This means that we start outputting whitespace around <math> elements when computing name from content as well. This feels fine, but as before, let me know if you disagree and I can hardcode what cases are OK. (As an aside, something seems broken with Name from Content when children are MathML? It's preexisting, and should probably be fixed in another CL) Change-Id: I2a4fc3cf137de5167d160860c1bda5151b38277d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4921470 Commit-Queue: Aaron Leventhal <[email protected]> Reviewed-by: Aaron Leventhal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1207629}
|
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
ThisIsBrokenbut 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.]
The text was updated successfully, but these errors were encountered: