w3c
Step 2.F.iii.c doesn't say if result should be appended with or without a space
Step 2.F.iii.c doesn't say if result should be appended with or without a space. The rest of the algorithm is more specific.
Related to this are the tests like:
<div id="test" role="link" tabindex="0">
...
(<span>Q</span><span>E</span><span>D</span>)
...
</div>
Some implementations are turning that portion into "( QED )" and others into "( Q E D )". The expectation is "(QED)" (sans spaces). That seems to imply that 2.F.iii.c should be an append without spaces. If that is indeed the case, what would be the expectation if the above snippet instead said:
(<span aria-label="Quod">Q</span><span aria-label="erat">E</span><span aria=label="demonstrandum">D</span>)
What if buttons were used instead of spans? What if divs were used instead of spans? What if there's a mix?
Edit: What if the middle span were instead a text input. We have this test case:
if given
<input type="radio" id="test">
<label for="test">foo<input type="text" value="bar">baz</label>
then the accessible name of the element with id of "test" is "foo bar baz"
I'm pretty sure the part of the algorithm which dictates calculating name from content of the label is also 2.F. And in that case our expectation is the insertion of a space.
I realize the whitespace situation is a mess, but clarification on the above would be helpful in terms of fixing implementations -- assuming they indeed need to be fixed (i.e. because our "(QED)" expectations are correct).
Notice there is some inconsistency in text expectations. On the one hand, we have this test, where the expectation is: "My name is Garaventathe weird. [...]":
<div id="test" role="link" tabindex="0">
<span aria-hidden="true"><i> Hello, </i></span>
<span>My</span> name is
<div><img src="file.jpg" title="Bryan" alt="" role="presentation" /></div>
<span role="presentation" aria-label="Eli">
<span aria-label="Garaventa">Zambino</span>
</span>
<span>the weird.</span>
...
Then we have another test, where the expectation is '2 4 6 8 10':
<label for="test">
<span class="hidden">1</span><span>2</span>
<span style="visibility: hidden;">3</span><span>4</span>
<span hidden>5</span><span>6</span>
<span aria-hidden="true">7</span><span>8</span>
<span aria-hidden="false" class="hidden">9</span><span>10</span>
</label>
User agents currently either add a space in both cases (Firefox) or none of them (Chromium). Firefox uses the presence or absence of whitespace between the inline elements as the deciding factor, like UAs do when rendering. Chromium will also follow this behavior soon.
User agents currently either add a space in both cases (Firefox) or none of them (Chromium). Firefox uses the presence or absence of whitespace between the inline elements as the deciding factor, like UAs do when rendering. Chromium will also follow this behavior soon.
This change has finally landed in Chromium so it behaves like Firefox now. For the sake of completion, WebKit behaves like them with regard to spaces (tested with Epiphany/GNOME Web).
Actually, it seems even more tricky, maybe linked to the display property of elements.
Trying with
<button>
<span>inline</span><span>no space</span>
</button>
<button>
<span>inline</span> <span>with space</span>
</button>
<button>
<div>block</div><div>no space</div>
</button>
<button>
<div>block</div> <div>with space</div>
</button>
<button>
<div>block</div><span>inline</span>
</button>
<button>
<span>inline</span><div>block</div>
</button>
Chrome (Version 97.0.4692.99) gives me "inlineno space", "inlinewith space", "block no space", "block with space", "block inline", "inline block" Firefox (V 96.0.3) gives me "inlineno space", "inline with space", "block no space", "block with space", "block inline", "inline block" (haven't tested on other browsers)
So, it seems both agree that display: block (I guess) creates spaces in the accessible name, which we should take into consideration in the clarification of the step.
Actually both inline and block level properties need to be taken into account, because it's also possible to take two block level elements and style them with inline properties to erase any whitespace between them. This issue is also documented at https://github.com/w3c/accname/issues/16
I thought we had made progress on this topic a while back, but it looks like I need to go through it again.
Should we take inspiration from the innerText algorithm?
It seems to indicate when there is a visual space (or new line) and it might makes sense to reproduce that for getting name (then replace new line by spaces and collapse adjacent spaces).
@accdc, @jaragunde is working on a PR for the AccName spec to solidify correct computations for hidden content, based on a lot of recent work in Chrome's implementation (requires Canary).
Sounds great, thanks!
Is this different from the issue of inline versus block level elements adding or not adding whitespace between them when processed recursively?
In this Blink PR we decided to add whitespace around the computed name of a descendant (if it wasn't already there) if the descendant satisfied one of the following:
- is
display: inline-block - is
display: inline-flex - is
display: inline-grid - is
display: inline-table
Is that something that makes sense? If it does I assume it could be formalized using lingo from the CSS display spec, although I'm not too well versed in that area.
