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

Thank you Alice, apology accepted. I really appreciate. Allow me to apologize in turn to you, Brian,  Joanie, and anyone else who felt that what I wrote was dismissive of your expertise. Regardless of my intent, which was not to dismiss, if you felt that way, I was misbehaving, and I am sorry.

----

Based on all that, what I'm hearing is that the way things are currently implemented give the expected result the vast majority of the time for a low implementation cost, and that switching to what I have been suggesting in order to cover the remaining i18n cases would be much more expensive, and would make things worse if the transition was poorly coordinated between browsers vendors and AT vendors (which is likely to happen when the AT vendor and the Browser vendor are not the same).

I think that's a fair point, and justifies a lack of appetite for switching.

At the same time, even though you say (and I believe you) that this is not generally what people want, I think it would be OK for an screen-reader to have a setting allowing the user to ask for transformed text to be read as if untransformed. If anyone wanted to do that, it would not necessarily have to be implemented by changing the text in the accessibility tree to untransformed; it could be done by having an extra attribute carrying the necessary information. I'm not saying that most users want this, nor that most screen readers ought to have that option. Just that it would be inappropriate for the spec to forbid that.

If we agree on the above, then I think we can consider that from a user's point of view, the differences between the current approach and the one I suggested earlier are implementation details of `text-transform`. They get the content rendered in the most appropriate way, with a range of presentational options based on which software they're using.

What I would not like for us to do is change the design of text-transform to require that ATs must never convey the untransformed content to the user, and to add new values to `text-transform` that rely on that assumption so much that meaning of the document changes if you do not apply the transform. 
* It would do a disservice to AT users to restrict the allowable options
* it would be break forward compatibly of existing browsers that do not have that feature with new content that would use it
* it would break the content when network problems cause css to fail to load
* it would break the content when viewed with UAs that don't support CSS (crawlers, RSS distribution of the same content, etc)

In conclusion, I think that:
1. The exact shape of the data exposed in the accessibility tree and other accessibility oriented APIs is out of scope for CSS.
2. Separately from the specific accessibility tree API design, the design of `text-transform` itself needs to be that the semantics of the text are unaffected, and therefore it MUST be acceptable to convey the text untransformed to the user, and that ATs (or other tools, like reader mode or alexa or what have you) MAY take styling information including `text-transform` into account when presenting that text to the user (and possibly that they SHOULD take that information into account for case related transforms, but I'd say that that too is out of scope for CSS).
3. Any values that clash with this model don't belong in that property.
4. In the spec where we define the accessibility tree (or in a note in the CSS spec if there's not good normative spec to host this for now), we probably need to define:
4.1. for compat with existing ATs (and because we may well do the same thing again even if we did not have the compat constraint), the text in the accessibility tree must? should? be pre-transformed for the case-related text-transforms
4.2. that non-case transforms (`full-width`, `full-size-kana`) must not be reflected in the text of accessibility tree
4.3. To support the ability of ATs to give further presentational options to their users, we should expose the transform property as an attribute on the accessible object, as suggested by joanie in https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-475796027

I think that this would be good because:
* it doesn't require changes to existing implementations of case-related text transforms
* It does allow non-case related, i18n text-transforms to work out of the box with existing screen readers when browsers start supporting these values
* it enables the broadest range of presentational options for screen-readers that care to offer them to their users
* it does not stop us from adding the math related transforms discussed in #3745 (I'll give details in a separate comment, probably in that issue, how we can reconcile the two).

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

Received on Friday, 29 March 2019 10:38:13 UTC