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

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.



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

Received on Friday, 29 March 2019 07:06:08 UTC