AccName: additional text node tests #42407
Conversation
|
@sivakusayan @aleventhal @MelSumner @jnurthen @jcsteh Do you agree with my test expectations about interior whitespace? (currently lines 56–72, but that could change) For example, several tests are failing across the board (see CI results in the checks above: WebKit, Chromium, Gecko) b/c of a distinction between regular space chars and non-breaking space chars. It's interior space, which is less strictly specified than leading/trailing space. I think my pasteboard even normalized the differences here: Of NoteThe WPT helper method We could also normalize interior whitespace to match (these tests would then pass across the board) and add a new method that preserves whitespace exactly, which we could use on a limited number of tests. |
This is my preference FWIW. Maybe with a comment in there to revisit in the future. I think there are some whitespace issues that need to be resolved just because we can't seem to get consensus on where they should be or where they should be compressed due to different interpretations and implementations. |
|
Seems like that’s the consensus from the related AccName issue too, so I’ll make it happen. Thanks all. |
…nd other browser accessibility engineers
cookiecrook
force-pushed
the
comp_text_node
branch
from
0810b9e
to
a324df1
Compare
…d by HTML and referenced by ARIA/AccName
don't normalize/trim the expectation, only the result
|
Recycling CI. |
thx jugglinmike Co-authored-by: jugglinmike <mike@mikepennisi.com>
Co-authored-by: jugglinmike <mike@mikepennisi.com>
|
|
||
| <h1>text/element/text nodes, no space</h1> | ||
| <span role="button" tabindex="0" class="ex" data-expectedlabel="buttonlabel" data-testname="span[role=button] with text/element/text nodes, no space">button<span></span>label</span> | ||
| <div role="heading" class="ex" data-expectedlabel="headinglabel" data-testname="div[role=heading] with text/element/text nodes, no space">heading<span></span>label</div> |
There was a problem hiding this comment.
The test looks good, somewhat related observation:
I noticed that HTML validation passes for this role="heading" instance without aria-level however, it's currently a MUST that aria-level be provided. Should this fail validation?
(This seems related to ARIA-only parsing errors like lack of explicit grouping for role="radio").
There was a problem hiding this comment.
It's an Author MUST, but I don't think it will change the results of these tests... If you know otherwise (e.g. missing aria-level changes the computedlabel?), then we should have a new file testing how that and similar required attributes affect the label... Otherwise, heading level will get tested after we have a direct accessor to it. (See WICG/aom#197 and WICG/aom#203)
Closes web-platform-tests/interop-accessibility#37