You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NOTE: The purpose of text-transform is to allow for presentational casing transformations without affecting the semantics of the document. Note in particular that text-transform casing operations are lossy, and can distort the meaning of a text. While accessibility interfaces may wish to convey the apparent casing of the rendered text to the user, the transformed text cannot be relied on to accurately represent the underlying meaning of the document.
The last sentence makes it seem like all accessibility APIs are concerned with is the casing, which is not true. Assistive Technologies (AT) convey any number of font and rendering characteristics, including the spacing of text-transform: full-width; (conveyed by HoverText on Mac/iPad and presumably ZoomText on Windows). Of note: there are downstream bugs wrt to some ATs or speech engines, but exposing the wrong data to the API is not a good solution.
I'd propose the following replacement for the note:
NOTE: The purpose of text-transform is to allow for presentational casing and layout transformations. Note in particular that text-transform: full-size-kana; casing operations are lossy, and can distort the meaning of a text. While the transformed text cannot always be relied on to accurately represent the underlying meaning of the document, accessibility interfaces may still need to convey the rendered text to the user to accurately present speech, braille, or re-rendered text characteristics, including case and spacing.
The text was updated successfully, but these errors were encountered:
Most case transforms are lossy though, not just full-size-kana. Even uppercase is lossy, as in some contexts casing is significant; and in others we drop information for the case transform (e.g. Greek drops accent marks when uppercasing).
NOTE: The purpose of text-transform is to allow for presentational casing and layout transformations. Note that casing mutations are lossy, and can distort the meaning of a text. While the transformed text cannot always be relied on to accurately represent the underlying meaning of the document, accessibility interfaces may still need to convey the rendered text to the user to accurately present speech, braille, or re-rendered text characteristics, including case and spacing.
And maybe a separate note about full-size-kana output expectations?
The last sentence makes it seem like all accessibility APIs are concerned with is the casing, which is not true. Assistive Technologies (AT) convey any number of font and rendering characteristics, including the spacing of
text-transform: full-width;
(conveyed by HoverText on Mac/iPad and presumably ZoomText on Windows). Of note: there are downstream bugs wrt to some ATs or speech engines, but exposing the wrong data to the API is not a good solution.I believe all parties acknowledge
full-size-kana
is problematic to convey due to its resulting change in meaning of the text as outlined in Example 5.I'd propose the following replacement for the note:
The text was updated successfully, but these errors were encountered: