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 ***@***.***>

[aardrian]

@MelSumner If you can gather proposals for all the concerns you raised above, I think this would make a good deep dive topic. But we need to have some direction and it seems like you have spent some time thinking about these.

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

I have and have been following along for the last 12 years (and there are bugs open 14 years or more) and even discussing copying styled text results in valid arguments both ways.

[MelSumner]

Capturing points of view

First, I think it's important to acknowledge the differing points of view here.

1. Some users: give me everything on the screen and let me decide if it's important or not.
2. Some users: give me the information that is necessary to complete my task.
3. Some designers: I want to create something usable and visually aesthetic.
4. Some engineers: let me use the spec to inform my code and my tests
5. Implementors: difficulty implementing; browsers already use
   rendered text in order to get whitespace accuracy
6. Braille display support: seems most natural for the Braille display to reflect the capitalization seen on the screen (factually accurate? Source?)
7. Implementors: this change has already been implemented (question: what about everything that is now broken because of this non-spec implemented change?)

Let's assume for the sake of this audience (and because I think it's a safe assumption), accessibility advocates/people working on this problem are empathetic towards all sides of this issue.

Existing guidance

Let's also consider the the guidance we've been providing to designers and developers for many years.

1. The outcome must be machine-readable code. AT reads what is in the DOM. Markup is semantics.
2. CSS's original intended purpose was styling/presentation. While some CSS properties may explicitly state to not rely on them for semantic meaning (e.g., referenced specifically in this issue in the OP), CSS is getting more and more complex, and these days can have a serious impact on what is presented to the user with AT.
3. Code to the spec, file bugs with the browsers. (General guidance)
4. Accessibility is: can users use this application in the way it was designed to be used?
5. An equivalent experience is what we're going for, it doesn't have to be precisely the same, but equivalent. Equally as usable, but maybe there are some variations for different types of users.

(Note: I've loosely paraphrased here, I will look for links)

Web usage examples

What cases do we se on the web now? Let's consider some examples (non-exhaustive list):

1. Some confirmation modals for destructive actions, e.g., "To confirm removal, type DELETE"
2. Design: Taglines for articles on news sites, where the category of the headline is in tiny uppercase letters above the title (vox.com has examples of this on their home page)
3. Design: Websites that use text-transform:uppercase for their site title (first visible link, usually top left in the nav)
4. Design: h3 element design using text-transform:uppercase; letter-spacing: 1px; (or button elements that have their text transformed to uppercase)
5. Content: Your company has people who write copy, and they indicate what things should be capitalized in the text content that they write.
6. Abbreviations (a shortened form of a word or phrase)
7. Acronyms (the initial letters of a phrase that form a word)
8. Initials (the first letter(s) of a person's name)
9. Abbreviations that are not typically capitalized (i.e., e.g., etc.)

Action steps for AccName spec

Potential action steps we could take here for AccName spec:

1. Acknowledge the way things are. Add a note for authors to say "this is the current way things work" and leave out any guidance about whether it should or should not be that way.
2. Update the spec to reflect guidance for vendors and authors.
3. Do nothing, accept that this is one of those things that can't be fixed, for now.

Recommended future discussion

I am deeply troubled by the trend of browsers making changes that are in direct conflict with the specification. I think we need to have a serious discussion about the future of the web/spec and our role in it. Specifications are supposed to be instructions for browser vendors, but it seems as though specifications are often asked to change to reflect what browsers have chosen to do. The working group should be considering and discussing the root cause and future appropriate action. I am sure there is a balance to be had, and that reasoned discussion will be an essential part of resolving the state in which we currently find ourselves. I do not believe that what is happening now is sustainable in any meaningful sense.

ETA: I am sympathetic to the difficult work of engineering browser code, there are a lot of competing priorities and it is a difficult job. I recognize that The WPT intends to help with this, but perhaps we (as specification contributors/authors) could coordinate more so that we are able to delineations that are complimentary instead of contradictory. I apologize if any of the discussion suggestions come across as inflammatory. My intent is to encourage deeper conversation, even if it's difficult.

[aleventhal]

Hi Melanie, I think the Braille display point is a good one and should be added.

[MelSumner]

@aleventhal I pulled in your comments from prior comments, apologies for leaving them out. I think I need more details on the braille implementation point, can you point me to a doc where I can read more, or let me know what that bullet point should say?

[aleventhal]

Basically someone raised it on the call, that it seems most natural for the Braille display to reflect the capitalization seen on the screen.

…

On Fri, Aug 2, 2024 at 2:38 PM Melanie Sumner ***@***.***> wrote: @aleventhal <https://github.com/aleventhal> I pulled in your comments from prior comments, apologies for leaving them out. I think I need more details on the braille implementation point, can you point me to a doc where I can read more, or let me know what that bullet point should say? — Reply to this email directly, view it on GitHub <#239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZWQISFUSNSTHVSVJHLZPPGZ7AVCNFSM6AAAAABIN5FJO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVHE2DANBUGQ> . You are receiving this because you were mentioned.Message ID: <w3c/accname/issues/239/2265940444 ***@***.***>

[MelSumner]

Basically someone raised it on the call, that it seems most natural for the Braille display to reflect the capitalization seen on the screen.

i've added it! thanks!

[aardrian]

In the "Existing guidance" heading, you use "we". I know you mean the royal we, but items 1–3 I have not, personally, said in years. Terrible trainings, old books, simple guides, etc. still make some of those claims (along with SEO nonsense), but broadly those are wrong. It seems part of this challenge is deciding if or how much we want to also factor in existing wrong guidance.

As for your "Action steps", Scott made an issue for item 1 in AAM.

Do you have a starting point for item 2?

[MelSumner]

@aardrian

1. Re: we, yes. But I'll update it. I'm trying to make the language as clear as possible.
2. Can you clarify what guidance is incorrect? Or rather how? I'd like to have the comment be as accurate as possible, without being overly-pedantic; I could add a recognition of the existence of nuanced caveats to keep it terse if that's the general concern. Especially re the first point, I still understand articles like Melanie Richard's article "from semantics to screen readers" to be correct and haven't read anything otherwise recently. Do you have another reference?
3. Since it's still an issue here in AccName, and hasn't been moved, I would expect to need to update this specification as well. Am I missing something?

I'm not sure what you're expecting here. I'm trying the best I can to gather responses and figure out a path forward for AccName.

[MelSumner]

I did some testing over the weekend and results are very inconsistent.

As such, we should probably stick a pin in this for now, write up a full analysis, and deep dive it.

[scottaohara]

Melanie Richard's article was, and is still an excellent resource on this topic. It also directly mentions that CSS can contribute to / alter the way browsers expose content to the a11y tree, or that screen readers can infer styling as they see fit (also via referencing the DOM or what the styles may expose in the a11y tree).

here is one mention of that from the article:

Generally speaking, modern web browsers wait until after style computation to build up any accessible objects. Browsers wait in part because generated content (such as ::before and ::after) can contain text that can participate in calculation of the accessible object’s name. CSS styles can also impact accessible objects in other various ways: text styling can come through as attributes on accessible text ranges. Display property values can impact the computation of line text ranges. These are just a few ways in which style can impact accessibility semantics.

I am calling this out specifically because I think it's important that we are all coming at this from the same baseline. CSS can be used to manipulate the presentation of HTML, adding extra content or styles which can convey important visual meaning. CSS doesn't manipulate the semantics of the HTML or the text content - the markup is still the markup, and the text is still the text. But the styles used come with their own information that can be important to communicate. browsers can expose that information by the a11y api, and screen readers / potentially other AT may expose that styling information to users (or not) - by default or based on settings.

[aleventhal]

These are good points. Also, display:none is probably the most impactful CSS feature when it comes to the a11y tree, both in terms of frequency and the fact that it can remove things from the a11y tree.

[MelSumner]

I've updated the "existing guidance" section specifically re: CSS. I acknowledge that it was too simplistic and didn't take current CSS into account in the way that it should have. Ty for the feedback! 👍

[aardrian]

@MelSumner

Can you clarify what guidance is incorrect?

Briefly...

1. The outcome must be machine-readable code. AT reads what is in the DOM. Markup is semantics.

The second and third statements are not strictly true. The DOM is manipulated by CSS (with the display:none example being the easiest example but CSS generated content being another easy example) on the regular. Mark-up does not really expose semantics, it is often arbitrary unless the browser, AT, or some other tool actually do something with it. So sure, output needs to be machine-readable, but the machine can not understand it or choose to ignore it.

2. CSS's intended purpose is presentation. Don't rely on it for semantic meaning. (Referenced specifically in this issue in the OP)

Regardless of its stated purpose, it absolutely impacts semantics. See my multi-year campaign about display properties stripping semantics. See CSS generated content. See alt text making it into CSS image properties. CSS regularly adds content and mutates semantics.

3. Code to the spec, file bugs with the browsers. (General guidance)

I would flip these because you don't want to code to the spec when you know doing so harms the output. For example, I would love <datalist> to be supported, but I am not adding it to sites because it has little support. I would love to span column headers in tables, but doing so will create broken table experiences for some users. So file the browser bugs first, see if they plan to do anything, and ensure that those features aren't simply dumped from the ever-changing versionless spec instead.

Edit: I see the things on which I was commenting changed while I was writing this. So, I dunno, adjust as appropriate?

[cookiecrook]

Capturing some things mentioned on the call last week:

• The browsers are aligned wrt accessibility text output being transformed, and if I recall correctly, have been aligned since before that line was written into the CSS spec, though it was not testable at the time. (If nothing else, all engines being aligned on accessibility behavior should give people pause to break that alignment. Especially since some of us strongly feel the behavior is correct.)
• The transformed text is needed for the screen reader (braille output and other functions like character navigation). In my experience, screen reader users want to know what is rendered on screen. Why would any spec mandate that only AT users get a different experience? That only screen reader users should be unaware of what's actually rendered?
• The original bug mentioned ("CALL US" is mispronounced in a particular context, and later "ADD TO CART") is not even a browser bug or screen reader bug. It's a speech engine bug, downstream from the screen reader or other text-to-speech AT. One which I can't reproduce on any of the speech engines I tested on Mac. Here are some of the test cases, each voice representing a different engine.

say -v Fred "CALL US"
say -v Samantha "CALL US"
say -v Eddy "CALL US"
say -v Susan "CALL US"

IMO, it's not appropriate for CSS or ARIA to try to "fix" a speech engine bug by mandating behavior in browser engines that is known to misrepresent renderings to AT uses, and known to cause downstream issues with braille displays and single-character review.

PS. One exception is the full-size-kana value, which as I understand, all parties agree should be resolved. It's a much more pervasive and serious problem that can't be addressed by speech engines. An explanation of how this differs from the other values can be found in Example 5 of the spec.

[cookiecrook]

@MelSumner discovered that it may be even more specific than the speech engine. The same speech engine (IIRC) with an en-uk voice Daniel, and an en-us voice Samantha, pronounces the acronym differently, probably due to a locale-specific dictionary. (FWIW, I'd still call this a bug well outside the scope of CSS or ARIA.)

say -v Daniel "AWS Manager"
say -v Samantha "AWS Manager"

Another engine also gets this one wrong.

say -v Eddy "AWS Manager"

PS. It may also be worth pointing out that this particular string would be unlikely to be triggered by text-transform.

[spectranaut]

Just commenting to add link to minutes of Aug 1 meeting: https://www.w3.org/2024/08/01-aria-minutes#t07