CSS text-transform should not affect computed name

[adampage]

During some recent JAWS testing, I encountered a “Call us” heading awkwardly pronounced as “Call U.S.”

The heading had been rendered with CSS text-transform: uppercase, and I was surprised to confirm that this presentational transformation had bled into the accessibility tree.

The CSS spec’s documentation for text-transform states:

This property transforms text for styling purposes. It has no effect on the underlying content, and must not affect the content of a plain text copy & paste operation.

Authors must not rely on text-transform for semantic purposes; rather the correct casing and semantics should be encoded in the source document text and markup.

In the spirit of that specification, I propose adding a note to the accname spec (possibly to the Name from Content section) to clarify that the computed name must remain unaffected by text-transform so that the author’s semantic casing decisions will be faithfully passed along to assistive technology.

I’ve submitted a few WPT subtests to accompany this issue. As it turns out, all 3 major browsers engines let text-transform affect the computed name. 😅 If the working group agrees, I’ll draft an update to the accname spec and also create implementation bugs (or boost existing ones, such as this Chromium issue).

[spectranaut]

Hi Adam! Nice catch, but this is something that is actually still being debated. Many think the spec should change, not the browsers, here is the context: https://github.com/w3c/csswg-drafts/issues/3775

[aardrian]

There is recent activity on this Chromium issue, though not sure it helps: https://issues.chromium.org/issues/40343523

[spectranaut]

Agenda for: Discuss how to track accessibility issues on CSS?

[MelSumner]

Are we suggesting that this should be explicitly outlined in ACCNAME spec?

FWIW,I think that what's reflected in the DOM is what should be reflected to the user (via screen reader).

I tried this out in CodePen and in the DOM it is in lowercase still: