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

Re: [csswg-drafts] [css-text] Add new CSS text-transform values for math (#3745)

From: James Teh via GitHub <sysbot+gh@w3.org>
Date: Wed, 27 Mar 2019 02:48:44 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-476945729-1553654923-sysbot+gh@w3.org>
Regarding accessibility, the line between content, semantics and styling is not as clear-cut as one might hope. Puristically, it's tempting to say that CSS is purely for styling and nothing else. In reality, that isn't entirely true any more in the real world.

Two examples which demonstrate this clearly:

1. If we say that CSS is purely about styling, then display: inline vs display: block would be irrelevant to accessibility. In reality, that isn't true. Whether several elements are rendered on the same line (e.g. a horizontal navigation bar or a credit card number input divided into 4 fields) can be just as useful/relevant for screen reader users as any other user.
2. If we say that CSS is purely about styling, then `:before` and `:after` content, list-style, etc. would not be exposed to AT users. In reality, this information can be very helpful (if not essential) to the user.

On the flip side, we've come to realise that we do *not* want to reflect CSS display: block on tables, display: contents, etc. for accessibility.

text-transform is a grey area, IMO. On one hand, it can cause weirdness for speech. On the other, if someone chose to render something a certain way visually in a particular view of the text, they clearly did that for a reason. Braille in particular tries to provide a mapping to prevalent visual text features. Braille has indicators for capitalisation, bold, italics, etc. You'll note that these are *not* called emphasis, strong emphasis, etc.; they are *not* purely semantic. When we talk about accessibility, we cannot think about speech alone.

Finally, there's a technical concern. We absolutely must support things like `:before`/`:after` content, list-style, etc. In order to do that, we need the rendered text, unless we want to duplicate that rendering in accessibility code, which opens up a world of mapping (e.g. text offsets) and sustainability problems. That means text-transform ends up coming along for the ride whether we like it or not.

GitHub Notification of comment by jcsteh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-476945729 using your GitHub account
Received on Wednesday, 27 March 2019 02:48:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:45 UTC