W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2019

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

From: joanmarie via GitHub <sysbot+gh@w3.org>
Date: Fri, 29 Mar 2019 13:37:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-478000147-1553866642-sysbot+gh@w3.org>
@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.

GitHub Notification of comment by joanmarie
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-478000147 using your GitHub account
Received on Friday, 29 March 2019 13:37:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:58 UTC