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.

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.



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

Received on Friday, 29 March 2019 07:27:26 UTC