Add name from content tests for CSS text-transform:full-size-kana

[adampage]

Closes web-platform-tests/interop-accessibility#137.

[adampage]

Hi @cookiecrook, I saw that there was already a distinct name_from_content.tentative.html file in the repo, so I globbed on to it. Would it be better to isolate these tests in a new file?

I created 2 subtests for this PR. The first subtest is a straightforward h3 heading that checks its name from contents.

The second subtest is a <ruby> construction. This seemed appropriate at first since full-size-kana was evidently conceived for ruby annotations in the first place? However, all 3 of the elements used there have no ARIA role and therefore do not support name from content, so I suppose this subtest is just straight-up invalid. 😅 Do you think this case is worth testing, and is there some other technique I could use?

[adampage]

Chrome and Firefox are both passing the first subtest.

[cookiecrook]

editorial clarity suggestions. thanks.

[cookiecrook]

I think the second example is more clear why this would happen. Ruby text can be small, so presenting it larger makes it more readable, even though a reader needs to mentally re-convert the text to understand the appropriate meaning.

However, in this first example, why would this ever be used in a heading? Should this subtest also be embedded in an <rt> element for clarity?

Also, these tests are missing sufficient sentence context, so there is no unambiguous "right" answer. Are you able to add enough that any future editors or reviewers of these tests know that the meaning should be "hospital" (not "beauty parlor") and "dragon" (not "reason").

[adampage]

Thanks, @cookiecrook. I’ve added sentence context for both subtests:

1. びょういんのかんじゃサービス (Hospital patient services)
   in which the transformation of びょういん (hospital) to びよういん (beauty parlor) is unambiguously wrong.

2. 竜の背に乗る (Ride the dragon‘s back)
   in which the furigana for 竜 is transformed from りゅう (dragon) to りゆう (reason), also plainly wrong.

I also updated the second subtest to enclose the <ruby> in a button, and then tested the accname of that button.

I’m still waiting for all the results to come through, but it’s notable in Safari that the accname of the button ignores the <rp> elements but does roll up the <rt> elements in addition to the kanji they’re annotating. This results in a confusing label of 竜りゆうの背せに乗のる that is both duplicative (it loosely translates to “Ride ride the dragon reason’s back back” 😅) and also allows full-size-kana to transform the AT-exposed text.

[cookiecrook]

Hi @cookiecrook, I saw that there was already a distinct name_from_content.tentative.html file in the repo, so I globbed on to it.

Yes, I would do it the way you did it.

The second subtest is a <ruby> construction. […] 😅 Do you think this case is worth testing, and is there some other technique I could use?

I also initially thought that would be a good test, but a) it's not a name-able element as you've discovered, and b) ruby is ambiguous wrt to labels, so perhaps these subtests should use something simple like a link or a button.

(Note: there are ongoing fixes for the duplicative ruby speech, despite the ambiguity in the spec. Best to avoid those in compartmentalized automation tests in the meantime.)

[cookiecrook]

"incorrectly" may be confusing... As it's the correct behavior for rendered text, but should not be transformed in the test exposed to the Accessibility APIs… Note: I expect implementors may have questions about how to achieve this, so it's good this is in a tentative file.

[adampage]

Here’s another cut at that. I also went ahead and commented out the second subtest.