Re: [csswg-drafts] [css-text] text-transform's design, intent and reality resolution (#3775)

Thanks for raising this. You are right that there is a disconnect, and that we should get to the bottom of it. I draw different conclusions though.

I think the current situation is muddled in three overlapping ways:
* The original design of text-transform does not prevent assistive technologies from also applying the transform to the text if it would be appropriate for the way they are presenting it to the user.
* Users of assistive technologies do not experience the accessibility tree directly. They experience the way screen readers (or their other assistive tool of choice) renders it to them. For such users, there is no observable difference between the accessibility tree containing transformed text vs the accessibility tree containing untransformed text to which the screen reader then applies the transform. But the later allows the assistive technology to make a choice about when to apply it or not, while the former does not.
* For now, the values of text transform that have been broadly implemented are those related to capitalization. Roughly speaking, case transforms are reversible, so voice synthesis can render uppercase text identically to lowercase text (macOS's VoiceOver does).

I think that while this doesn't prove the original intent of text-transform to be correct, it also doesn't prove that the current reality is a clear good match for users' needs. It could mean that the current approach is the right one, or it could mean that the current approach is a tolerable approximation because the cases where it really makes a difference haven't been exposed yet.

My assumption is that it is the later:

* I'd expect an upper-casing text transform to be the stylistic in the same way as a font-feature or a color change would be, and therefore that it should not in general be preserved, to avoid having `::first-line { text-transform: uppercase}` result in the first line being read in a screaming voice or spelled out, neither of which seem the intended effect. Indeed, in macOS, VoiceOver reads uppercase and lowercase text identically. The uppercasing may be used in the visual rendering to signal that something is a section heading, or maybe the content of an `<em>` element. The AT already has access to that information, and can signal it. It doesn't need to scream/enunciate/ping on top of that, and if it did want to, it can key that off the style rather than the text.

* Similarly, unless the screen reader undoes the transform or otherwise renders it moot, exposing the transformed text breaks `text-transform: full-width`. Using it to display "IBM" as "ＩＢＭ" can be desirable in Chinese / Japanese / Korean text (particularly but not only in vertical text), but that doesn't mean that it should be read aloud as "full width Latin capital letter I, full width Latin capital letter B, full width Latin capital letter M". I still want to hear IBM. It's significantly worse if the word isn't an acronym to begin with.

* Exposing only the transformed string defeats the point of `text-transform: full-size-kana`: りょ and りよ are different (the first is ryo, the second is riyo), but at the very small font sizes sometimes used in ruby, using the smaller ょ in りょ can make the text hard to see, and so authors sometimes want to display りよ instead of りょ despite the difference. The whole point of doing it using `text-transform: full-size-kana` rather than by hard-coding りよ into the DOM is so that screen readers can read it as ryo instead of riyo. For example, if the ruby for 無料 (which means free / costless) is encoded (as it should) as むりょう, that is read is muryō, and all is understandable. If it is encoded (or rendered into) むりよう/muriyō, this could be misinterpreted as 無利用, which means "useless". For a sighted reader, the potential confusion is probably preferable to the letter being too small to read, and they would see the original ideographs next to it, clearing things up if they can read them. But for someone going through a screen reader, it could be pretty confusing. If the screen reader reads both the original text and the ruby, you still hear "free and useless", and if it sustitutes the ruby for the original text, you would just hear "useless", instead of the intended "free (free)". Moreover, this transform is not reversible, so if the transformed text is exposed to the screen reader, there is no way the screen reader can untransform it to read it correctly.

Based on that, I'd suggest a different path forward than @bkardell 
1. Changes to assistive technologies:
1.1. ATs that currently effectively undo the transform (either by actually undoing it internally, or by rendering the transformed and untransformed content identically) don't need to do anything.
1.2. ATs that do to expose some special effect on transformed content (e.g. play a tone, or change voice pitch, in the case of an uppercase transform) should look up the style information and trigger the special effect based on that.
2. Browser engines should switch to exposing the untransformed text in the accessibility tree

If we do that, we can continue to use text-transform for its intended purpose. If we don't, we will need to accept that text-transform only works as originally intended in the cases where the transform is reversible by the assistive technologies, and may have to give up on it solving solving the broader related i18n problem.

@bkardell notes that:
> [browsers] expose the transformed text, universally. They didn't always, but they do now - and they do this consciously because they believe that that is the right thing to do.

I'd like a double check on this: is it indeed an intentional change? It could be, but it could also be an accidental side effect of rendering the accessibility tree off the render tree rather than the DOM. Or it could be the "implementation shortcut" I mentioned earlier, achieving the same effect as exposing the untransformed text and applying the transform in the assistive technology (in most cases so far, but not in all i18n cases) .

I wouldn't be surprised if it were accidental, nor if it was the "implementation shortcut". If it is a conscious decision distinct form the implementation shortcut, I am really curious as to what the reasons are.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-477842094 using your GitHub account

Received on Friday, 29 March 2019 02:29:46 UTC