CSS text-transform affects 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: w3c/csswg-drafts#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:

[MelSumner]

I'd encourage everyone to read the existing CSS specification text in the OG post.

Browsers have purposefully chosen to do the opposite of CSS Spec, and now we're suggesting to define conflicting behavior to CSS spec in AccName spec because it's what browsers do right now.

I strongly urge us to re-consider.

Another option would be to have CSS spec change first, but this is genuinely going to break the web in a lot of places. Well I guess since browsers do this, it's already breaking the web, we just didn't realize it.

I oppose making it AccName or HTML-AAM spec that if CSS uppercases it with text-transform then that's what should go to the AT. If authors want the information in uppercase letters, that's how the content should be written, and put in the DOM that way.

We'd be removing any method of having presentational uppercase text in the browser.

[aleventhal]

Hi Melanie, on my first glance I agreed with you, but I think there were some good counter arguments too. It would be helpful to address those, such as Braille display support, authoring, stability of existing implementations, difficulty implementing (because browsers already use rendered text in order to get whitespace accuracy), and the likelihood that future speech engines will become smarter because of AI. It's frustrating that CSS would not be purely presentational and that current implementations don't seem to agree with CSS spec text, but we can't just skip over the counter arguments either.

…

On Thu, Aug 1, 2024 at 2:10 PM Melanie Sumner ***@***.***> wrote: I'd encourage everyone to read the existing CSS specification text in the OG post. Browsers have purposefully chosen to do the opposite of CSS Spec, and now *we're suggesting to define conflicting behavior to CSS spec in AccName spec because it's what browsers do right now.* I strongly urge us to re-consider. Another option would be to have CSS spec change *first*. I oppose making it AccName or HTML-AAM spec that if CSS uppercases it with text-transform then that's what should go to the AT. If authors want the information in uppercase letters, that's how the content should be written, and put in the DOM that way. We'd be removing *any* method of having presentational uppercase text in the browser. — Reply to this email directly, view it on GitHub <#239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZTCQGPDFZFD4PDROJLZPJ2X7AVCNFSM6AAAAABIN5FJO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGY3DOOJZHA> . You are receiving this because you are subscribed to this thread.Message ID: <w3c/accname/issues/239/2263667998 ***@***.***>

[MelSumner]

@aleventhal We're taking away a design tool and there's going to be (or already is?) no alternative. The idea that AI is going to become smart enough to tell an author's intent is not something we have any real evidence for, and it would be foolhardy to believe that this would be the case.

Add a new aria- attribute for this? Sure.
Add a new HTML tag for this? okay fine.
Encourage content writers to make things in capital letters in the content? Yes definitely

But directly opposing CSS Spec AND completely removing a design tool for designers with no other way for them to do the thing? Seems not just bad but this-is-breaking-the-web bad.

Apologies if this comes across as super intense. I respect and support the work browsers are trying to do to put users first and provide a more inclusive experience on a web where code is of increasingly poor quality.

In this case, however, I just don't think that this is the way. I think we can do better than this.

[aleventhal]

No worries. I'm just suggesting the path forward for your idea is to make a solid proposal that addresses those other points. I don't have agenda on this issue, just trying to help.

…

On Thu, Aug 1, 2024 at 2:22 PM Melanie Sumner ***@***.***> wrote: @aleventhal <https://github.com/aleventhal> We're taking away a design tool and there's going to be (or already is?) no alternative. The idea that AI is going to become smart enough to tell an author's intent is not something we have any real evidence for, and it would be foolhardy to believe that this would be the case. Add a new aria- attribute for this? Sure. Add a new HTML tag for this? okay fine. Encourage content writers to make things in capital letters in the *content*? Yes definitely But directly opposing CSS Spec AND completely removing a design tool for designers with no other way for them to do the thing? Seems not just bad but this-is-breaking-the-web bad. Apologies if this comes across as super intense. I respect and support the work browsers are trying to do to put users first and provide a more inclusive experience on a web where code is of increasingly poor quality. In this case, however, I just don't think that this is the way. I think we can do better than this. — Reply to this email directly, view it on GitHub <#239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZXCSUAEPZ47NZ5JSJTZPJ4G5AVCNFSM6AAAAABIN5FJO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGY4TCMRZGI> . You are receiving this because you were mentioned.Message ID: <w3c/accname/issues/239/2263691292 ***@***.***>