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

I think I was not clear in my previous message, so I'll try again. I have tried making it shorter, but I'm only moderately successful here at being both succinct and complete.

No matter what we say about the accessibility tree, there exists cases where HTML documents are rendered without CSS:
   * reader mode
   * network failure
   * content being scrapped by some search engine crawler or similar
   * When new values of text-transform are created, by they are not supported by older browsers, so even if CSS is being applied, new values of text-transform may fail to apply.

Therefore, we cannot reasonably have a model in which is would be wrong and forbidden for a UA/AT to present the transformed text. I am *not* saying that there is a requirement for AT to present the untransformed text. I am saying that a requirement that no UA/AT must ever do so is not reasonable and could not be enforced even if we did decide on it.

Because of the above conclusion, the following claim would be invalid:
> Since text-tranforms can be relied on to be applied in all cases, including visually and in assistive technologies, it is a reasonable mechanism to use to introduce semantic differences in the content, allowing authors rely on them to tell apart things which would otherwise be the same in cases where it would cause misunderstandings if they were presented the same.

text-transforms cannot be relied on to be applied in all cases, and so they cannot be used to introduce semantic essential differences. It is not reasonable to write a contract or an algorithm with `let foo be [....] and let <span style="text-transform:something">foo</span> be [...]`. It is not reasonable to introduce new values of text-transform that claim that they can reliably be used that way. They cannot.

Once I've said that, I've made no requirement on how accessibility trees must store the text, or on how assistive technologies must present it. The best way to present a given piece of content, knowing how css wants to style it, in various environments, is a separate question. All I am saying is that it is indeed a question, and "transforms must be preserved always" does not derive from the inherent design of the text-transform property.

It has been stated that the vast majority—possibly all—users of assistive technologies, wanted in the vast majority of the cases—possibly all—that when text-transform changes the case of some text, that they be presented with the result of the transformation. This is the intentional behavior of screen readers today, implemented via how the accessibility tree is built. Since the current behavior is desired, let's not change it.

This is because users want it this way, not because of anything inherent to `text-transform`. 

There is, however, no strong compatibility requirement that transforms **other than**  case transforms (`full-width` and `full-size-kana`) be preserved in the accessibility tree. There is also no desire from the users the other values are designed to serve that they be preserved in the accessibility tree. As discussed at the beginning of this comment, the semantics of the text is what's in the unstyled document, and we just need to think about the best way to present it. Speech synthesis works best (in the case of `full-width`) or at all (in the case of `full-size-kana`) if these transforms are not preserved in the accessibility tree. So they should not be, even if case-related transforms are. (We may also want to add an attribute in the accessibility tree to indicate these transforms in case ATs want to signal that, but that can be added later, so there's no rush, and that does not invalidate the previous point).


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

Received on Wednesday, 3 April 2019 03:51:02 UTC