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

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](https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute) and [W3C](https://www.w3.org/TR/html5/dom.html#the-innertext-idl-attribute) 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?

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

Received on Friday, 29 March 2019 05:56:52 UTC