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

My understanding is that the question here was in essence:

"Can we agree that it is a fundamental part of the design of text-transform that it must in all cases be reflected everywhere including in the screen-reader rendering, and therefore that we can base decisions about future values on that fact?"

I believe the answer is no.

It is true that there are values of text-transform that affect the rendering in screen readers, and that's intentional on their part. For example changes of case.

* There are also values of text-transform that do not affect the rendering in screen readers, and that distinction is critical to their purpose. For example full-width or full-size-kana.

* In all of these cases, screen readers should also be allowed, if they so desire, to present the alternate view to their users (maybe on demand, maybe based on a setting… this is a UX problem, and is out of scope for the spec).

* There are cases where CSS doesn't load, so counting on it to change semantics is unreliable anyway.

The design principle, to me, is that text-transform does not alter the meaning of the styled text. User agents such as screen readers that provide a non-visual rendering may take that styling into account when deciding how to present the text, but it is not a thing that should be relied on as a design principle of this feature. (Whether users of a particular implementation can rely on that implementation doing is separate, and not particularly relevant here.)

The way to apply that principle to the proposed math related text-tranform would be:
- adding these transforms is OK.
- using these transforms to explain how various pieces of mathML markup (such as the mathvariant attribute) cause endering changes is OK.
- relying on these transforms to alter the meaning of the document, and to semantically distinguish between 'a' and '<span style=text-tranform:math-fraktur>a</span> is not robust.
- Markup is what needs to alter the semantics. The [spec of mathvariant attribute]( is already fairly clear about that, but it could be further clarified that it is expected to affect all renderings, including the accessibility tree and other non visual renderings.

GitHub Notification of comment by frivoal
Please view or discuss this issue at using your GitHub account

Received on Thursday, 2 July 2020 01:55:00 UTC