Bug 261565 – AX: text-transform: full-size-kana must not affect AT/speech output

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[fantasai]

Overview
  text-transform: full-size-kana must not affect speech output.

Steps to Reproduce:
  1. Load testcase:
     https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstrong%20style%3D%22text-transform%3A%20full-size-kana%22%3Eじゅう%3C%2Fstrong%3E%20must%20read%20the%20same%20as%20じゅう%20not%20じゆう%20(but%20look%20like%20じゆう%20not%20じゅう)%20.%3Cbr%3E%0A%3Cstrong%20style%3D%22text-transform%3A%20full-size-kana%22%3E%20カップ%20%3C%2Fstrong%3E%20must%20read%20the%20same%20as%20カップ%20not%20カツプ%20(but%20look%20like%20カツプ%20not%20カップ)%20.%0A
  2. Verify that 'text-transform: full-size-kana' is supported by comparing the visual rendering.
  3. Use VoiceOver to compare the speech rendering.

Additional Information:
  https://www.w3.org/TR/css-text-3/#text-transform-property
  Note that the mapping in the Small Kana Mapping Table is not a case mapping. These are different letters (with related, but different pronunciations) that happen to look similar. See examples in spec.

[Radar WebKit Bug Importer]

<rdar://problem/115504070>

[James Craig]

From some discussion with Elika, this might need to be limited to ruby, or at a minimum, we’d need test cases to make sure the other values (like text-transform: uppercase) were not affected by the change. 

Note that I’m still unclear as to why text-transform would be used in a way that affects the core meaning of the text, so perhaps we should discuss or require addition information before the change.

[fantasai]

> Note that I’m still unclear as to why text-transform would be used in a way that affects the core meaning of the text, so perhaps we should discuss or require addition information before the change.


This is explained in detail in the spec (linked above).

[fantasai]

`full-width` should also get the same treatment (use underlying untransformed text for AT), fwiw.

[James Craig]

I disagree about `full-width`... That's mostly likely an AT bug in automatic language detection; the characters are unambiguous, but the AT is choosing the wrong voice language. Filed <rdar://133412477> for that.

I'll also file a CSS spec issue for the "casing for accessibility" note, because it doesn't take into account the spacing context we discussed for AT like HoverText where rendered `full-width` chars would be expected.

[fantasai]

Created attachment 472124 [details]
testcase

[James Craig]

FYI fantasai: https://github.com/w3c/csswg-drafts/issues/10732

[Joshua Hoffman]

Pull request: https://github.com/WebKit/WebKit/pull/32125

[EWS]

Committed 282258@main (00c8f4758364): <https://commits.webkit.org/282258@main>

Reviewed commits have been landed. Closing PR #32125 and removing active labels.