[css-text] text-transform's design, intent and reality resolution

[bkardell]

It would appear that there is some real disagreement about text-transform and a gap of understanding between spec authors and implementation realities that I was not previously aware of (the gap, not the implementation). Had I been paying closer attention I could have pointed this out sooner and we might have been in an ever so slightly better place, so apologies for that.

Let me briefly summarize the state of things, as I see them.

1. The CSSWG designed the text-transform property (long ago) to exhibit specific qualities for both accessibility and copy/paste. Namely, thinking that is was important that this was stylistic in nature, not exposed to AT and that one should be able to get the meaning directly from the document content, even if there was no CSS.

2. Text-transform got used a lot on the web, including by people who understood it this way - in part, because many people explained it that way.

3. Browsers currently at least, and for a while now, actually do not work this way. They 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.

4. The CSSWG was not aware of this reality and continued to operate under that design. On Sept 2018, @frivoal opened a bug to (re-)add support for the full-size-kana ([css-text-3] text-transform: full-size-kana #3143) transform and based choices of that on the understanding of their original designs (# 1 above)

5. Firefox implemented support. To date, they are the only ones (I believe, according to compat tables) who support it. Firefox's accessibly tree does indeed contain the transformed text.

6. Based on how things actually work in practice, @fred-wang made a proposal that seems to fit into the platform in a number ways very well and similarly to much in the platform - but the fact that it specifically desires the actual behavior brought to light the disconnect between the two communities

So... we are kind of stuck now having a conversation where some members of the csswg feel that this is problematic and seems like a bug, not a feature and need to be fixed - and accessibility folks who disagree. This seems especially unfortunate for two reasons: First, but less importantly, because until this is resolved, I feel like no one is going to want to resolve on the specific ask of #3745 * which is a real shame because it seems like that is important to moving that larger and important effort forward.

Second, and most importantly, because it seems very unfortunate for everyone involved outside of this discussion. That is, if the experts and authors of specs and implementations cannot agree then what hope do average developers have of understanding and making things that actually service the real users that we all care about?

Here are my own 2 cents:

text-transform dates back to CSS 1 when situations were much different. There were no accessible browsers when it was imagined, there was no ARIA, AT, nor tools, nor underlying subsystems and so on.

I believe that as much as we may have tried to reason about things, they were, in part, even later on, somewhat aspirational and speculative. For various reasons, I do not believe it was even possible to include the right people or understand the right problems at the time for 'now'.

Fast forward though and these things do exist and are robust and there is a universally deployed, significantly interoperable answer to "how does text-transform actually work" today and there has been for some time. That arrived over time with feedback, practice, tools and users and millions of people consume "bajillions" of pages of existing content with those today and.. well.. the shape of it all is not what we might have understood or imagined.

There are now experts whose entire careers are now focused on these problems and more "natural pressures" in the ecosystem to ensure that they are coming up with the best kinds of answers. So... I am kind of inclined to resolve this by

a) taking them at their word and trusting their expertise that this is not a bug and not going to change

b) working to actually understand how things really work and try to better understand perspectives

c) celebrate that it works and it works the same

d) Teach and build on it so that CSSWG has good parameters for when adding a text-transform value might be good or bad.

This last one is important because until now (or at least until recently depending on how you want to classify the kana stuff) it has been limited to capitalization and that is one classification of things. How CSSWG members imagined this 'worked' wasn't really correct and it turns out that making something all caps is not actually going to scream random bits of text at people using a screen reader in ways that they can't hope to understand. But the kana stuff was considered differently and we should probably make an effort to review whether that is actually 'different' or still fine before it gets more widely used or implemented, and yes, it would be helpful for the MathML-related proposals.

• edit to correct the typo'ed off-by-one issue I accidentally linked to

[frivoal]

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.

[alice]

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.

This is (as Brian said in his original post) a conscious decision.

I can't speak to the full-size-kana case, but please believe us when we say we have spoken with numerous screen reader users who are developers themselves and understand all the facts, and they have consistently said they want the transformed text exposed by the AT under all circumstances. That is working as intended, regardless of how anyone who doesn't use a screen reader or other AT habitually may feel about it.

[frivoal]

please believe us

I fully trust that you know what you're talking about, and understand the needs of AT users better than I do. The problem is not one of believing, but of understanding. I'm not interested in being right, I'm interested in solving the problem. I didn't merely state that I thought my approach was right, I explained why. I would appreciate if you point out where I'm wrong, or if I'm not wrong what additional considerations I am missing. Merely stating that you know better doesn't help get to a conclusion.

[alice]

Joanie has explained this multiple times:
#3745 (comment)
#3745 (comment)

I'm not sure what I can possibly add to those explanations at this point.

Merely stating that you know better doesn't help get to a conclusion.

This absolutely isn't what I did. I said "we have spoken with numerous screen reader users who are developers themselves and understand all the facts, and they have consistently said they want the transformed text exposed by the AT under all circumstances".

It seems that you're stuck on that particular point - you don't seem to believe, even after hearing it from multiple different people, that that is actually what AT users want. I can only assure you that having spoken to AT users who know enough to make an informed decision, that they do want that, and ask you to take that on faith.

[AmeliaBR]

Expecting assistive tech to "undo" a text-transform is not reasonable: transforms are lossy operations. (E.g., once mixed-case text is converted to all uppercase, you cannot deduce the original casing from the rendered text and transform operation.)

The options are:

• Expose the transformed text as the effective text content after CSS processing (which also includes whitespace normalization, removing any display: none or visibility: hidden text, inserting CSS generated content, etc.). This is what all modern browsers seem to do.

  HTML (both WHATWG and W3C versions) also currently requires text-transform to be exposed as part of the innerText IDL property (which also exposes the whitespace and hidden element processing, but does not include CSS generated content).

• Expose the transform as a style attribute on the original text (similar to how bold/italic formatting are exposed to accessibility APIs), and expect assistive tools to determine how to expose the transformation to end users. From everything we've heard, it sounds like this would require a lot of implementation changes from a lot of different software types.

  Browsers would need to separate text transform from the other CSS text processing steps and keep track of the intermediary result. Accessibility APIs may need to be modified to have a way to expose the text-transform operation. Assistive tech would need to check for the transform style & find a way to expose it to users, which may involve implementing an equivalent character-by-character transformation step.

Now, asking for all those implementers to make those changes would make sense if there was a strong accessibility purpose. But we've had multiple accessibility experts say that for the most commonly implemented text transformations this is not what users want. Unless we get evidence to the contrary from people doing usability research with assistive tech users, I don't think we're going to convince anyone to change their implementations.

So, the next question is: what to do about text transformations where exposing the transformed character would be bad for accessibility?

Which seems to be only the (recently added & still not widely implemented) full-size-kana option. @frivoal: were options other than text-tranform considered for handling this typographic style? Would it make sense to describe the change in terms of a font-size adjustment instead of a conversion to different characters?

[frivoal]

I really is not because I don't believe you. It is also not because I don't care about users of screen readers. Please don't assume ill intent on my part. Please also extend me back the courtesy of believing that I too might know what I am talking about as well.

I have read Joanie's points. I have not dismissed them.

• Joanies' comment explains that users of a screen reader want the screen reader to be able to do something like

  Use higher pitch
  Play a tone
  Say "cap"
  

  I believe that. Users want this. Ok. I have faith in your understanding of AT users's expectations. That does not say why it is desirable to do that based on the text in the accessibility being pre-transformed, rather than the screen reader triggering those effects based on the styling information.

  It also does not say why they don't apply the same effect (higher pitch, playing a tone, saying cap etc), when using font-variant: small-caps;, or if screen readers already do that, why they couldn't look up the text-transform property the same way.

• She has said:

  Screen readers, as a general rule, want to present the content sighted users see. Exactly how it got rendered is, more often than not, irrelevant.* Furthermore, it's a drag for an AT to have to take every single bit of accessible text, retrieve some additional property "just in case", and occasionally do additional work to transform it. The render tree already contains the final/displayed version, so please share that with me. 😄

  *But if any ATs might have a need, exposing the transform property as an attribute on the accessible object shouldn't hurt anything and should be relatively easy to implement within the user agent.

  That leads me to believe that it would be equally good from AT users's point of view if the accessibility tree exposed the untransformed string + the transform, and screen reader did the transformation / effect themselves. It certainly would just be less convenient for screen-readers implementers. "It would be less convenient to implement" may be an argument worth considering, but it is very different argument than "It would be wrong". I've already acknowledged that it was a more convenient implementation strategy (as long as we only care about case transforms), and I was asking if there were reason other than that.

But implementer convenience doesn't trump end user's needs, and speakers of languages written in something else than the Latin alphabet are users too. Here's an example based on an sentence in an ad on my screen right now:

国内線でWIFI Serviceは無料！

This means “Free WIFI service on domestic flights".

If you use text-transform: full-width (not the full-size-kana entry recently introduced), which is a perfectly reasonable thing to do for typographical reasons, it gets turned into

国内線でＷＩＦＩ　Ｓｅｒｖｉｃｅは無料！

If I ask MacOS's VoiceOver to read that string, the pronunciation of the word "service" is garbled and is not understandable, even with the content correctly language tagged.

[alice]

I really is not because I don't believe you. It is also not because I don't care about users of screen readers. Please don't assume ill intent on my part. Please also extend me back the courtesy of believing that I too might know what I am talking about as well.

That's fair. I apologise.

It also does not say why they don't apply the same effect (higher pitch, playing a tone, saying cap etc), when using font-variant: small-caps;, or if screen readers already do that, why they couldn't look up the text-transform property the same way.

This is a reasonable point. font-variant styles do not get exposed the same way - this is either an oversight, or a reflection of the fact that smallcaps styles do differentiate between capitals and lower case letters unlike the text-transform case, or somewhere in between.

...
That leads me to believe that it would be equally good from AT users's point of view if the accessibility tree exposed the untransformed string + the transform, and screen reader did the transformation / effect themselves. It certainly would just be less convenient for screen-readers implementers. "It would be less convenient to implement" may be an argument worth considering, but it is very different argument than "It would be wrong". I've already acknowledged that it was a more convenient implementation strategy (as long as we only care about case transforms), and I was asking if there were reason other than that.

I think the issue is that it would likely constitute a regression for users until all ATs caught up, which may never happen.

But implementer convenience doesn't trump end user's needs,

Totally agreed, but we have to be pragmatic as well - for the text-transform: uppercase case, users have a "good enough" experience without anyone needing to change anything, and would not be happy if a change were to lead to them missing information.

That logic may or may not apply for other text transformations.

If you use text-transform: full-width (not the full-size-kana entry recently introduced), which is a perfectly reasonable thing to do for typographical reasons, it gets turned into

国内線でＷＩＦＩ　Ｓｅｒｖｉｃｅは無料！

If I ask MacOS's VoiceOver to read that string, the pronunciation of the word "service" is garbled and is not understandable, even with the content correctly language tagged.

That sounds like a much worse experience than the text-transform: uppercase situation, I agree. It doesn't seem unlikely that if you were to ask a Japanese-speaking screen reader user (who for all I know may use a different screen reader which already works around this problem) whether this was the experience they wanted, we would get a different answer to the text-transform: uppercase situation, and it doesn't seem unreasonable to treat these cases differently based on their different merits.

[frivoal]

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 [css-text] Add new CSS text-transform values for math #3745 (comment)

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 [css-text] Add new CSS text-transform values for math #3745 (I'll give details in a separate comment, probably in that issue, how we can reconcile the two).

[joanmarie]

@frivoal: If you remove the capitalized-via-transformed text, every screen reader which wants to present that capitalized text as part of its standard presentation is going to have to do extra work:

• Check every last element just in case it's been capitalized via text-transform. Odds are it hasn't been, but one never knows.
• Do the actual transformation -- taking into account any localization issues.

As for why this transformation is needed, I, as the screen reader developer, am not putting those dot-6 instances in the braille text or adding a tone for each capitalized word. I'm taking the rendered text -- which, again, all user agents give us -- and passing it along pretty much as-is to the libraries which do that actual work. Those lower-level libraries need the transformed text.

People already complain that screen readers are non-performant. Please don't give us even more work to do. The user agent has already done the work to render the transformed text and can give it to screen readers for free.

Regarding presenting the untransformed text (i.e. treat it as if it were not capitalized), screen readers and their users can already do that for speech quite easily: They just disable the capitalization presentation settings. Then, when the speech libraries do their thing, they fail to use higher pitch, they fail to say "cap" and they fail to play a tone because they've been configured not to do so. The end result is the text sounds uncapitalized.

[bkardell]

what to do about text transformations where exposing the transformed character would be bad for accessibility?

I think fundamentally @AmeliaBR is on to it here but I want to add a few questions that I think are important and amelia intends but are not explicitly stated:

1. can those two things share a property if necessary (ie, is it ok/desirable if AT does something diff with kana stuff if that is what should happen)
   1.1) If not, is it really too late to reimagine that one as something that isn't called text-transform? If so, can someone tell me why? I'm sure if that is the case there is a reason, it would be helpful to have right here if possible. It seems to me it is relatively recently to have been brought back to wg and ff's is the only implementer and it seems problematic on this already.

2. Maybe most importantly: How do we decide this? I would like to propose that we really need people who are not in the wg involved in that conversation because a number of wg folks have reasoned about this very differently historically and I'm not sure we are fully well suited to judge. Some of this may be answered by florians statement about what is not in the domain vs what is, but I think we need to articulate carefully there or be sure we include the right experts at any question

[AmeliaBR]

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.

Probably the best way to introduce such a thing would be through the browser, rather than the screen reader, as an accessibility override of the CSS (text-transform: none !important). Anything else would have all the same implementation obstacles of requiring browsers to expose both transformed and untransformed text to the screen reader.

Edited to add: a "no text-transform" setting might also have other accessibility applications in the browser, e.g. for some people with dyslexia all caps is problematic. Maybe also full-width.

[upsuper]

Which seems to be only the (recently added & still not widely implemented) full-size-kana option.

I would argue that full-size-kana itself is just a bad transformation, regardless of whether it's for visual or screen reader. I myself have found it's hard to tell the real pronunciation when I read a Japanese book with this transformation.

[frivoal]

I would argue that full-size-kana itself is just a bad transformation, regardless of whether it's for visual or screen reader. I myself have found it's hard to tell the real pronunciation when I read a Japanese book with this transformation.

Sure, but that's the entire point: when the text is too small, some authors do this anyway, but if they do it in the source document, the correct pronunciation is lost. This transform is not an invitation to use large kana where small kana should be used. The whole point is that if large kana is going to be displayed, authors should be able to still use small kana in the document.

[frivoal]

If you remove the capitalized-via-transformed text, every screen reader which wants to present that capitalized text as part of its standard presentation is going to have to do extra work:

Sure, which is why I am no longer proposing to do that.

Please don't give us even more work to do. The user agent has already done the work to render the transformed text and can give it to screen readers for free.

Right, and in my last message, I am saying that we should continue to do that. See "4.1"

You sound like you're disagreeing with me, but you're writing in opposition to points that I am not defending.

[joanmarie]

Right, and in my last message, I am saying that we should continue to do that. See "4.1"

You sound like you're disagreeing with me, but you're writing in opposition to points that I am not defending.

Apologies. I'm afraid some of the comments got a tad long and I missed (or misread) 4.1. Thanks for the clarification.

[frivoal]

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 scraped 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 untransformed 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).

[css-meeting-bot]

The CSS Working Group just discussed text-transform's design, intent and reality resolution.

The full IRC log of that discussion

<dael> Topic: text-transform's design, intent and reality resolution
<dael> github: https://github.com//issues/3775
<dael> astearns: Wanted to have this introduced so can make a bit of progress before bringing in more people
<dael> birtles: I don't see where this was spec originally in the design, but at some point it became a stated thing we have talked about about the intent fo text-transform and what it exposes to screen readers and why
<astearns> s/birtles/bkardell_/
<dael> birtles: Feel like I dropped the ball a bit on kana discussions because I know it wasn't reality and assumed other people did too. Some of the text stuff I don't feel I cam comment so wasn't paying close attention
<florian> q+
<dael> bkardell_: Opened a different issue requesting something that is inline with how screenreaders work. That changes to how we have designed to not expose text to screenreaders. It's come up that it does not match reality
<astearns> ack bkardell_
<dael> bkardell_: AT and browsers have chosen universally to expose transform text. I'd like to consider that so that we can properly discuss the other issue
<dael> bkardell_: My position is that the ones that exist and in wide use are stated design principle is out of touch with reality. It's a concious choice that's what users want. At a min our principle needs some finesse
<IanPouncey> q+
<astearns> ack florian
<dael> florian: The discussion is a bit long winded, I'll jump to where we are. I don't see the same contridiction of bkardell_ if we look a little deeper. DOn't think ti's interesting to debate what screen reader users what, the exprests have said. Screen readers do not give access to raw doc, they present it. It's easier to include the transform. I don't think that makes semantics change
<Rossen> q+
<dael> florian: I don't think we could do that. There are places where we don't present CSS so we can't say that text-transforms are an intrinsic part of doc that can't be removed. If screenreaders as one UA think best way to present is to apply the text-transform, great. But I don't think we can go from there to never not allow them to be applied. If you introduce a new text-transform old browsers won't know
<AmeliaBR> q+
<iank_> q+
<dael> florian: I thinkw e have to rec that the doc is the doc and the text transforms need to be allowed to apply. I think the claim that case transforms are desirable is credible, but I don't want to generalize to say all transforms always must be preserved. I think cjk and i18n transforms you want the other way.
<dael> florian: I think we need to discuss transform by transforms, but can't say all must be preserved
<astearns> ack fantasai
<dael> fantasai: I agree with florian that text-transform can't be intrinsic part of doc semantics. They were designed as a way to have this distinction partly. If we don't have them to diff doc and visual rendering we'll have to find a way to do it.
<dael> fantasai: Someone suggested creating a custom font, I don't want to get intot hat arms race
<dael> fantasai: I'm not sure how deeply this investigated in the past. I don't see anything in bugzilla. Chrome issues had people arguing on both sides. I don't know if this has been inestigated deeply enough. We need to talk to the people we need to talk to and figure out what to fall out. If no discussion on Gecko it's prob what's convenient
<astearns> ack IanPouncey
<dael> IanPouncey: Few points, to reiterat bkardell_ it seemed to those of us who work with screen readers that this was common knowledge, that's on us. For what florian said I think misconception about where problem lies. I'ts not screen readers doing transform, it's the browser and a11y tree exposing it
<florian> q+ to respond to IanPouncey
<dael> IanPouncey: It's not screen reader doing anything in most modern browser. Any of the ideas of a screen reader making a decision about what to present is problematic b/c you cannot reverse a transform to uppercase b/c you don't know what char were uppercase
<dael> IanPouncey: Speculating on this, I wonder if similar issue for content is on teh radar. I think there was an assumption when prop introduced that it's not exposed to screen readers and it is now. I wonder if there's a similar problem there
<astearns> ack Rossen
<fantasai> s/figure out what to fall out/figure out what to do. It's possible the current situation is what fell out of original implementations, and screenreaders just dealt with it but it's not ideal/
<dael> Rossen: Way screen readers work is a long discussion. How text is represented also heavily depends on current platoform support and AT consuming that ingo. nvbia on windows will have different characteristics to express richness of text comparred to narrator using ui automation
<fantasai> Point about delivering transformed text through AT meaning screenreaders can't access original text even if they want to is imho important
<dael> Rossen: One thing I know from interacting with the community and a11y wgs and immpl a11y the thing I can tell you is a lot of people think of screen readers for the blind. It's part of the users but not all. Most people are those with low vision. They can see parts of the screen. So when you start producing disparity between rendered results and what screen reader represents it becomes confusing
<dael> Rossen: Consider editing scenarios- most people will navigate text by character to check spelling. If at that itme you have text transform that caps for example for them to not know it's upper case will be confusing. Same reason why we map ital to em, lots of font features that map to a11y prop I don't see why this should be unique
<dael> Rossen: Other thing I want to give a big shout out, CSSAOM would be ideal place to continue this discussion
<astearns> ack AmeliaBR
<dael> AmeliaBR: There's 2 aspects to the discussion. What should happen, how is best way to expose full information. THen specific practical issue in that we have recently added values ot text transform with some impl and this new prop for math variants
<fantasai> wrt checking spelling in editing environment... ideally you want to know what text you're actually typing, for when the text transform goes away -- source text should be following standard capitalization rules, would be problematic if ::first-line { text-transform: uppercase; } led someone to type in all-caps when replacing one word with another in the first phrase of a para
<dael> AmeliaBR: By putting it all in text-transform it forcecs us to treat them the same for exposing before or after transform values
<dael> AmeliaBR: Even if not complete agree on optimal for exposing case changes I'm trusing florian that exposing CJK typgraphical is a problematic situation from a11y.
<dael> AmeliaBR: If mathML comes through it's very important to expose transformation.
<fantasai> generally, editing text with text-transform turned on is going to be very confusing regardless...
<iank_> q-
<dael> AmeliaBR: With these different semantic impacts it might be worth discussing if these should be split up, even if it's transform to long hands that could all reset by a shorthand but there is a text-transform case that's different then CJK text-transform. If we sep to different prop we can start talking semantics and what stange transformations happen
<astearns> q+
<dael> AmeliaBR: Esp in terms of what's exposed to a11y, copy/paste APIs, lots of places where people use text-transform and if they're not all equal maybe use different properties
<astearns> ack florian
<Zakim> florian, you wanted to respond to IanPouncey
<fantasai> reason to have separate longhands is needing them to cascade separately... if the only concern is what impacts they have, we can categorize within the spec
<AmeliaBR> s/a11y, copy/a11y, HTML innerText, copy/
<IanPouncey> q+
<dael> florian: I am aware about diff IanPouncey mentioned between what screen readers do and what's in at. Idea is that text in AT would be end transformed text and have the original information so screen readers can make decision. In case of case transforms if every screen reader wants to do the same thing with it and the current AT does the transform already it will be uphill to untransform. For case transforms if it's a standard today fine let's leave it
<bkardell_> are we on to the math case already?
<dael> florian: But that's what I want to Japanese which is keep untransformed text and keep information about transforms so that screen readers can add extra information if they want. The Math case I think is kind of related. I don't thinkw e can rely on the transforms to change document semnatics.
<dael> florian: If we want to introduce a new semantic differencec we have to introduce it in the document and that can impact the AT tree. We can't just change the font and claim it lets us introduce semantic differences that would change the meaning of the document. upper case is useful but not changing doc meanings. If we want to introduce math it will fail in all cases
<dael> astearns: To respond to AmeliaBR- I think the idea of separating properties is interesting but maybe not entirely nec. If e want we can spec what happens to values or prop and they can differ.
<dael> astearns: To respond to florian I think there is prob a fallback that can work for new math transforms. If you see support you get fractor, if you don't you do extra styling
<dael> florian: And it disappears in read
<dael> astearns: Fair
<AmeliaBR> q+
<astearns> ack astearns
<astearns> ack IanPouncey
<dael> florian: If you want to style that's fine. Introducing fundimentally different semantics is not fine.
<florian> s/is not fine/won't work/
<Rossen> :)
<dael> IanPouncey: Cautious +1 to expose detail of transform and original content. I can see if there's any appetite for that. Hopefully wecan get idea if that's possible. Also acknowledging the prompt to add CSSAAM to this discussion
<astearns> ack AmeliaBR
<dael> AmeliaBR: Follow up on florian concern about semantics in document. The request for math transforms is from MathML as a way to desc behavior of MathML attribute in a way that can be consistantly impl. That is something where there is semantics in doc level but nice to be able to describe it. Maybe also use same effects in more decorative cases
<dael> florian: Fair and useful so thing into a11y tree is the transformed and may be useful
<dael> astearns: We're at time. The call bridge will stay open if people want to chat and then put the discussion in the issue
<dael> astearns: Thank you all very much

[AmeliaBR]

From the post telcon discussion, a few points which I though were worth recording (other people who were there feel free to correct my interpretation or add other points):

• From @frivoal: Current reality (factoring in assistive tech and other things like reader mode) is that text-transforms of case may or may not be exposed to end users & so we should not create/encourage any situation where the meaning of the content relies on the transformed text always being exposed or never being exposed.

• From @fantasai: Ideally, ATs would get the untransformed text plus information about the transform style applied (similar to how they get information about bold, italic, etc.).

• From @AmeliaBR: Given the compat concerns and the amount of software involved, changing the value that is exposed for the primary text is likely to be problematic. So, probably need to keep exposing text after case transforms. But it might be possible to add a way to expose the untransformed text as a progressive enhancement.

  @atanassov strongly reiterated the complexity of the software ecosystem (browsers give data to platform specific APIs which are also used for other applications or document types, and the APIs then pass it along to specific tools like screen readers) and how in many environments this software is not well maintained. So changing well-established behavior is very bad, and adding new features is complicated.

• From @frivoal: The compat concern isn't an issue for new transformations, and compat needs might actually require different handling of these transformations. The current pattern of exposing post-transformation text would create an accessibility regression if browsers started recognizing e.g. the full-width transformation and exposing full-width characters to a screen reader (e.g., VoiceOver) that reads them out by reading out the full name of each character instead of reading out the words.

[jfkthame]

I see that https://bugzilla.mozilla.org/show_bug.cgi?id=1541668 has been filed on this.

In looking at how Gecko might be persuaded to ignore the full-width and full-size-kana transforms for purposes of the accessibility tree, I notice that there's a fairly close relationship between what is exposed for accessibility and what is exposed by HTMLElement.innerText.

Which raises the question in my mind, should innerText continue to respect all text-transform values (as it currently does in Gecko), or should it respect only the case-related transforms and ignore the full-width and full-size-kana ones, as proposed for accessibility?

[Crissov]

As long as .textContent contains the real, non-transformed plain text, .innerText can do whatever, in my humble opinion.

[AmeliaBR]

should it [innerText] respect only the case-related transforms

I think so, in order to retain a single order of operations for string manipulation, because there are steps that aren't included in innerText that need to be included in the accessible text:

1. Remove hidden child elements (display: none or visibility: hidden or hidden because of shadow trees).
2. Collapse whitespace.
3. Apply case-related text transforms. → innerText
4. Flatten shadow trees (not sure whether it's intentional that this isn't part of innerText, but anyway).
5. Insert CSS generated content. → accessible text
6. Apply CJK typographical text transforms.

[fantasai]

@jfkthame @AmeliaBR OK, can we split off the discussion of what .innerText should do into a WHATWG issue? This issue is already complicated enough, and .innerText has its own compat restrictions and weirdness.

[bkardell]

so... I was debating whether to add this to the conversation, but now I feel like I have to.

This property transforms text for styling purposes. It has no effect on the underlying content, and must not affect the content of a plain text copy & paste operation

is also not a thing that would appear to reflect reality when I tested it. Chromium and webkit browsers for me seem to copy and plain-text-paste as transformed text, matching the AT (which totally makes sense to me and is maybe a whole other thread I dont want to pull on) but FF does not - which, I guess means that it gets the value for the AT and the plain text paste differently?

[jfkthame]

That's come up before (sorry, I don't have a reference to previous discussion offhand). Personally, I consider the chromium/webkit behavior to be a bug.

[ByteEater-pl]

I think that AT are actually doing two thing which conceptually (and would it be practical to give users the choice actually?) are very different modes of operation. It's mixing them that causes confusion.

1. Rendering a document in speech media.
2. Representing aurally what's visible (or would be) on the screen.

CSS only specifies requirements for 1 and they entail ignoring properties which are for visual media only (though not display: none or structural pseudoelements). For 2 those tools could do anything, including consulting text-transform, display: block and other CSS properties.

[frivoal]

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.

However:

• 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 rendering 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.

[fred-wang]

* 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.

This was included in the proposal as I thought it could help motivate the feature for people who for some reason are not interested in native math rendering support or even don't like MathML (but apparently, this had the opposite effect). For example, I believe MathJax or KaTeX generates something like <span style=font-family: special-woff-font-for-fraktur>a</span> for special rendering and to infer special semantic.

For native MathML implementation, this use case is not important at all, so I'm happy if the CSS spec say text-transform shouldn't be used for semantics.

* Markup is what needs to alter the semantics. The [spec of mathvariant attribute](https://www.w3.org/TR/MathML3/chapter3.html#presm.commatt) 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.

For the record MathML3 is outdated, the reference for CSS-based browser implementation is

mathvariant: https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute
text-transform proposal: https://mathml-refresh.github.io/mathml-core/#new-text-transform-values

Note that @bkardell plans to open new CSS issues for the proposals and relaunch the discussion soon, so hopefully we can move "CSS Extensions for Math Layout" to relevant CSS specs instead.

We could improve the MathML Core spec to clarify it is expected that the change for mathvariant affects non-visual renderings as you suggested. Actually we already had that in mind, but were waiting for a consensus on the present CSSWG issue.

[css-meeting-bot]

The CSS Working Group just discussed [css-text] text-transform's design, intent and reality resolution.

The full IRC log of that discussion

<dael> Topic: [css-text] text-transform's design, intent and reality resolution
<dael> github: https://github.com//issues/3775
<florian> https://github.com//issues/3775#issuecomment-652733256
<dael> AmeliaBR: Is brian here?
<Rossen_> q?
<dael> florian: I'd like to speak about it anyway
<dael> florian: Comment jsut posted
<dael> florian: Issue not suggesting we change spec. It was fundimental design of text transform. If we can all agree fundamentally text tansform behaves in a certain way we can use that to build other things. It seems clear we can't agree this is the way it works
<dael> florian: I can give more details, but I think conclusion is no we can't agree, please close this.
<dael> florian: I can give arguments why I think it's the opposite, but the conclusion is we cannot agree it's this other thing.
<dael> Rossen_: Anyone from Igalia here to talk about this?
<dael> myles: Are you proposing close?
<dael> florian: Yes, close with no prejudice. I have nothing against hte math features. Can we agree the fundamental meaning of the document, no we cannot.
<dael> myles: I'm happy to close
<dael> AmeliaBR: I think we have to formally agree to disagree in sense of accepting some values of text-transform might have meanings that should pass to assistive and some should be stylistic and that's just the way it is. We cna't seem to agree all one or the other
<dael> fantasai: I disagree with that. There are values that are clearly only presentational. There are other values...entire putpose of text transform being in css is to make it presentational. a11y layer might want to know and it's appropriate to pass some information to it. I think text-transform beign a css property is not intended to convey semantics.
<dael> fantasai: If you're using a11y api it may take aspects into account but it should not be used for semantics
<fantasai> s/aspects/aspects of presentation/
<fantasai> s/it should/text-transform should/
<dael> florian: Personally I agree with fantasai but issue was that it is in all cases semantic. We certainly have not agreed it's always semantic and never presentational. Maybe we convinced people of fantasai view. THere's nothing to be done here.
<dael> fantasai: I'll take an action item to put some text in the spec clarifying where we're at. We'll review text and decide if we like it
<dael> AmeliaBR: If you write what you said it's an improvement and as far as we can move forward with this.
<dael> ACTION fantasai put some text in the spec clarifying where we're at on issue #3775

[acli]

In certain use cases, text-transform is functionally equivalent to font-variant. A plausible use case is small caps through Google Fonts – you have to do it with text-transform because Google Fonts does not preserve OpenType features so small caps, when offered, is always a separate font.

I do this myself and while I prefer to use OT features, I have to keep doing this as long as I have to use Google Fonts.

[bkardell]

Fwiw I support closing this issue. I feel like our discussions and @fantasai's recent edits to attempt better are fine (I think - 'document' is a much better word than 'text' here, for one) and we should be unblocked for the related discussion.

That said, I think it might be better phrased to say that I don't think this is the right issue/venue for the larger question(s) that I think still hold a bit for me. I just think that this isn't the right issue or place to clarify this further, it probably isn't this narrow or even about a single issue - some of the principles of how/why we design things and how we think they should work, and how they work in practice etc seem like they are sometimes a little muddy and could use a clear articulation of design principles that all of the necessary groups (not just CSSWG) can agree to. In retrospect, I think this is precisely what W3C TAG design principles is talking about, so, hopefully that's a better place than this and I think we should close the issue.

[r12a]

I'd like to add my point of view. It seems to me that the problem here is that the distinction between semantics and presentation is being dangerously blurred if text is copy/pasted in uppercase, or pronounced with emphasis, because it has a text-transform applied to it. I think this is a dangerous way of thinking about things: the semantics should be in the markup, and the CSS should be ingorable and potentially evanescent styling only.

Florian gave some examples of how CSS may not be present when the text is read. Here are some other scenarios where i think pronouncing or copying the transformed text rather than what's in the markup actually introduces incorrect semantics, and breaks the intended use of the text-transform property.

Florian already mentioned the Japanese case, with the kana that is resized purely for the benefit of visual readers. The actual text that is read or copied needs to maintain the distinction between small and normal sized kana for proper comprehension by TTS, for copy/paste, for searching, etc. This is really important, but the obvious solution is being elbowed out. I may have missed it (the thread is long), but i don't remember anyone proposing an alternative solution to this real-world problem that needs to be addressed.

Bringhurst's Elements of Typographic Style shows examples of uppercased headings, run-in sideheads, upper-cased text following versals.

The style that the i18n WG uses for documents used to apply text-transform to remove capital letters from L2 and L3 headings. However, we certainly wanted people copying that heading to have the capitals in the unstyled text – what we did was just intended to be sugar-coating. And in fact a while ago we actually removed that transform from the L3 headings, and changed L2 headings to ALL CAPS (using the Gill Sans font, which is specially designed to make such text readable) (see an example at https://www.w3.org/International/questions/qa-visual-vs-logical.en). No semantics where changed here. We don't want screen readers shouting the L2 headings at people, or emphasising them in any special way because they are all caps. If we did, we'd have put the ALL CAPS in the markup, since that's the semantic layer.

It's common, when using drop caps, to continue the first word on the line using uppercase letters. Again, this is a purely stylistic device, which may not be appropriate or desirable in documents if those same docs are viewed in a different visual context. The intent is not to emphasise the first word in any way when rendering it through TTS, or copy/pasting the text into a different page with different style conventions.

These presentational devices seem to reflect the intended purpose of the text-transform property. I'm concerned that we are likely to break these useful applications, without recourse, by assuming that style information carries semantics.

[frivoal]

The note is in place, @bkardell who opened this issue originally supports closing, and subsequent comments by @acli and @r12a are going in the same direction. Agenda+ to confirm closing.

[astearns]

@frivoal I'm not sure we need meeting time for this. We made non-normative editorial changes that are enough for this iteration, and I think we can just close this with “commenter satisfied” for the disposition of comments.

[yisibl]

Please note: Chrome changed the behavior of copying to the clipboard a while ago, and now text-transform does not affect the actual text copied to the clipboard.

• https://chromium-review.googlesource.com/c/chromium/src/+/5399744
• https://x.com/yisibl/status/1796028058459423063
• https://x.com/tomayac/status/1641374529497841666