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.
<rdar://problem/115504070>
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.
> 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).
`full-width` should also get the same treatment (use underlying untransformed text for AT), fwiw.