search

w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
61 stars 23 forks source link

Consider allowing CSS `inline` display to modify the whitespace character joins in accessible name computation #225

Open cookiecrook opened 8 months ago

cookiecrook commented 8 months ago

From another PR that I'm mostly gutting due to merge conflicts and an inability to land on consensus in time for the looming AccName CR.

On the [18 Jan 2024] call, @accdc said [the references to spacing should be dependent on] whether or not the element had an inline or similar value, versus a block or similar display value. I assume the "block-like" values include inline-block, cell, and the like. I'm not sure if display:contents or other newer layout tooling values are considered "block-like" or not.

Presumably the interior contents would be promoted for "adjacency" consideration?

If the above is correct, I also presume that would mean if either of the adjacent elements (or their pseudo when joining pseudos) had a "block-like" display then use a space joiner...

Unknown at the moment whether that is implementable, and also unknown is how far the render tree should consider "adjacent" render objects... For example, if the adjacent DOM element is display:none (or display:contents), is the expectation that the renderer check the next adjacent element or pseudo that is not display:none? What about a display:inline element with visibility:hidden?

_Originally posted by @cookiecrook in https://github.com/w3c/accname/pull/168#discussion_r1458058588_

cookiecrook commented 8 months ago

I think Bryan's summary was that inlines would concat without space.

<span>foo</span><span>bar</span> = "foobar" <span>foo</span> <span>bar</span> = "foo bar" (interior space between inline elements meaningful)

and "block-like" values (pretty much every display value besides inline) would be joined with a space, even if only one of the adjacent ~nodes was non-inline.

<div>foo</div><span>bar</span> = "foo bar"

Bryan's thought was this also applies to pseudo elements, but the interior extra concatenated space is only used if both the pseudo and its element are display:inline or equivalent.

Again, I'm not yet sure if this is implementable, and there are a number of other open questions...

cookiecrook commented 8 months ago

If the solution gets complicated enough, such as a table listing all the CSS display values (or other properties for that matter) and how they affect Accessibility API related mappings, then there might be a need to revisit the idea of a CSS-AAM spec.

fantasai commented 8 months ago

CSS's most current definition of how to most correctly convert to plaintext is here btw: https://www.w3.org/TR/css-text-4/#plaintext Note that if you're not in an inline formatting context, collapsible whitespace sequences get collapsed away. (I would add an expectation that generated content via ::before/::after/::marker would be included in the conversion.)

cookiecrook commented 8 months ago

Thanks @fantasai... that and the cross-referenced section, CSS Text: 4.3.1. Phase I: Collapsing and Transformation, seem like the most promising path forward.

spectranaut commented 8 months ago

Discussed in today's meeting: https://www.w3.org/2024/02/01-aria-minutes.html#t05