1281158 - Implement alternative text for 'content' property

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Sebastian Zartner [:sebo]]

The CSS Generated Content Module Level 3 defines a way to specify alternative text for the 'content' property value by separating it via a slash after the last <content-list>.

This bug is meant to implement this feature.

Sebastian

Comment 1

[張俊芝(ZHANG Junzhi)]

This feature is mainly used for accessibility, I am not familar with accessibility. I am not sure if Firefox already has functionality of providing speech of the alt text.

If it's not what Firefox, mainly as a visual user agent, takes into account in a high priority for now, I'd like to suggest this issue be devided into two steps. In the first step, we don't implement the speech functionality, we can just let Firefox recognise the value.

Comment 2

[Bill Goldstein [:aja] (UTC-6)]

Note: Chromium 'Intent To Ship: Alternative Text for CSS Generated Content' on 2019-07-01:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nC5p6W8nM3g

Comment 3

[Hamish Willee]

FWIW I think the Firefox behaviour here is more buggy than just "not implemented". See the example here: https://developer.mozilla.org/en-US/docs/Web/CSS/content#image_combined_with_text - even though an image is provided and present, because the alternative text is not understood by Firefox the whole line is ignored.

So there might be space for another bug somewhere between implementing support and not falling over because there is text after the url for the image.

Comment 4

[Sebastian Zartner [:sebo]]

Technically, this is not an issue of Gecko but the way how CSS works. If its value is invalid, the whole property is ignored.
And that is what is happening here. The value is unrecognized due to the unimplemented syntax for the alternative text.
For the engine it is basically the same as if you wrote content: foo.

So what you can do in this case is write the content property twice, once without and once with alternative text. Applied to the example on MDN that is:

a::before {
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico");
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") /
    " MOZILLA: ";
  font: x-small Arial, sans-serif;
  color: gray;
}

or alternatively:

a::before {
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico");
  font: x-small Arial, sans-serif;
  color: gray;
}

@supports (content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") / " MOZILLA: ") {
  a::before {
    content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") /
        " MOZILLA: ";
  }
}

If Gecko parsed the new syntax without actually supporting alternative text, it would be a "false positive".

Having said that, I think that might be something that the CSS Working Group should discuss as it is clearly a benefit in this case if authors just have to write the property once.

Sebastian

Comment 5

[Hamish Willee]

Thanks Sebastian - appreciate the detailed explanation and workarounds. I clearly don't know enough CSS (I'd thought if it could parse the url() part then that was "success" - but thinking about it .... there is no way to know that whatever comes after it might not in some way modify the validity of the previous syntax in some way - so it really has to be all or nothing). I will assume you will take up with the WG if you think there is something helpful that might be done.

Comment 6

[Sebastian Zartner [:sebo]]

(In reply to Hamish Willee from comment #5)

I will assume you will take up with the WG if you think there is something helpful that might be done.

Yes, here's the link for reference: https://github.com/w3c/csswg-drafts/issues/7952

Sebastian

Comment 7

[Hamish Willee]

Thanks Sebastian, I have another query. Consider this line:

content: url("https://mozorg.cdn.mozilla.net/media/img/xfavicon.ico") / " MOZILLA: "

What should happen if xfavicon.ico does not exist/cannot be found on the server?

Chrome displays nothing for this case. Rachael Andrew she thought that this was spec compliant - Chrome treats the invalid image as no image and so neither the image nor alt is used https://w3c.github.io/csswg-drafts/css-content/#typedef-content-content-list

I'm not so sure - the case isn't covered specifically as being "invalid". What I do know is that "as a developer" I would have expected the alt text to be used if the image could not be loaded for any reason.

Comment 8

[Sebastian Zartner [:sebo]]

(In reply to Hamish Willee from comment #7)

Chrome displays nothing for this case. Rachael Andrew she thought that this was spec compliant - Chrome treats the invalid image as no image and so neither the image nor alt is used https://w3c.github.io/csswg-drafts/css-content/#typedef-content-content-list

The specification currently doesn't explicitly mention that the alternative text should be displayed. Though it says that the alternative text must be used for speech output, i.e. screen readers.

I've checked that right now again in Chrome and when you look at the Accessibility side panel within the Elements panel, the alternative text is listed within the accessibility tree as 'img "MOZILLA:"'.
But I've also tested it with Google's own screen reader extension. And with that it is not read out loud.
I am far from an expert in this area and I am also normally not using assistive technologies like screen readers. So I can't really say whether this is an issue on Chrome's side, the extension or the OS'es accessibility API.
Though from an accessibility standpoint this obviously does not work as expected.

I'm not so sure - the case isn't covered specifically as being "invalid". What I do know is that "as a developer" I would have expected the alt text to be used if the image could not be loaded for any reason.

I assume you mean shown by saying "used". If so, I'd possibly agree, as it's a similar case as the alt attribute in <img> elements. Though again, the spec. currently doesn't say anything about displaying the text. Therefore, I've created another issue in the CSSWG to discuss that: https://github.com/w3c/csswg-drafts/issues/7974

Sebastian

Comment 9

[Hamish Willee]

Hi Sebastian, Thank you for all your help.
Sadly, I did mean "display".
I started from the MDN example "Image combined with spec" rather than the spec, and that is what it seems to imply (nothing about screen readers):

This example inserts an image before the link. If the image is not found, it inserts text instead.

But then if you look at what Chrome does, it displays both image and text if the image is present and neither image or text if the image is not present. Worst of all worlds. I added a note for this against the issue with that link.

Comment 10

[Sebastian Zartner [:sebo]]

Attachment: Alternative text for content in Chrome's accessibility tree.png

(In reply to Hamish Willee from comment #9)

This example inserts an image before the link. If the image is not found, it inserts text instead.

But then if you look at what Chrome does, it displays both image and text if the image is present and neither image or text if the image is not present. Worst of all worlds. I added a note for this against the issue with that link.

No, it doesn't. To be clear, "Mozilla Home Page" is the link text. The alternative text for the image is " Mozilla: ", which isn't displayed, at least in my Chrome 107. So, if the alternative text was displayed, the text would be " Mozilla: Mozilla Home Page". If the image can't be loaded, Chrome does not display " Mozilla: ". Though it exposes it in its accessibility tree.

Sebastian

Comment 11

[Hamish Willee]

Thanks Sebastian - I must be going mad in my old age.

Comment 12

[James Craig]

FYI this just landed in WebKit, and previously in Chromium.
https://bugs.webkit.org/show_bug.cgi?id=159022

WPT tests are here:
https://wpt.fyi/results/accname/name/comp_name_from_content.html?label=master&label=experimental&aligned&q=label%3Aaccessibility

Tests Source:
https://github.com/web-platform-tests/wpt/blob/master/accname/name/comp_name_from_content.html

This is part of Interop 2024, too.

Comment 13

[Tim Nguyen :ntim]

I added parsing tests here too: https://wpt.fyi/css/css-content/parsing

Comment 15

[Sebastian Zartner [:sebo]]

Safari doesn't currently support this feature.

Sebastian

Comment 16

[Daniel Holbert [:dholbert]]

They've added support and it just hasn't hit release yet (see comment 12).

Comment 17

[Sebastian Zartner [:sebo]]

Ah, sorry! I missed that.

Sebastian

Comment 20

[Thomas Wisniewski [:twisniewski]]

As per bug 1878355 comment 4, support for alt-text is required to pass the interop2024 accessibility WPT accname/name/comp_name_from_content.html

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1281158 - Improve interaction of ThinVec in the style system. r=#style

This is the logical continuation of bug 1121792. This improves on the
existing support by totally removing all the manual nsTArray bindings,
which have always been a bit clumsy.

This is a prerequisite for bug 1281158 because I want to use ThinVec to
avoid a few extra heap allocations in the computed values of the Content
property.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1281158 - Parse alternative text for the content property. r=#style

This doesn't yet expose it to a11y but that will be done by the a11y
folks, since this blocks some of the a11y interop test-cases.

Modify the tests to not hit the network.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/087da46fdf65
Improve interaction of ThinVec in the style system. r=dshin
https://hg.mozilla.org/integration/autoland/rev/df46563babe2
Parse alternative text for the content property. r=dshin

Comment 24

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46167 for changes under testing/web-platform/tests

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f684b69e09a
Fix browser_parsable_css.

Comment 26

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/087da46fdf65
https://hg.mozilla.org/mozilla-central/rev/df46563babe2
https://hg.mozilla.org/mozilla-central/rev/5f684b69e09a

Comment 28

[Sebastian Zartner [:sebo]]

This needs to be added to https://github.com/mdn/browser-compat-data/blob/29e3fd727df4f5431beeeb0b9924726fe4ea06ab/css/properties/content.json#L53, depending on bug 1896047, with a hint about accessibility.

Sebastian

Comment 29

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 30

[Dave Letorey]

I can see this feature working in Nightly - 128.0a1 (2024-05-15) (64-bit)
But not in Beta - 127.0b2 (64-bit)

Is this going to be released in 127?

Comment 31

[Emilio Cobos Álvarez (:emilio)]

No, it's behind a flag, because it needs the actual accessibility engine support which is being worked on in bug 1896047. So most likely 128.

Comment 32

[Dave Letorey]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

No, it's behind a flag, because it needs the actual accessibility engine support which is being worked on in bug 1896047. So most likely 128.

I have found a flag for this: layout.css.content.alt-text.enabled although I can't find a flag for bug 1896047 so the image is not being exposed to the accessibility tree.

Comment 33

[Sebastian Zartner [:sebo]]

Attachment: Alternative text exposed in accessibility tree

The flag also controls the output in the accessibility tree. With Nightly 128.0a1 (2024-05-20) I can see it being exposed in the accessibility tree, as well.
(Tested on https://developer.mozilla.org/en-US/docs/Web/CSS/content#result_5)

Sebastian

Comment 34

[Dave Letorey]

The flag also controls the output in the accessibility tree. With Nightly 128.0a1 (2024-05-20) I can see it being exposed in the accessibility tree, as well.
I can nopw see that the flag is enabled by default in 128.0a1.
I was referring to what happened when the flag was turned on in 127.0b4, in this instance there is no Imaged exposed to the Accessibility Tree.
So I think what I am pointing out here is that the flag in 127.0b4 is not working as in 128.0a1

(Also tested on https://developer.mozilla.org/en-US/docs/Web/CSS/content#result_5)

Comment 35

[Sebastian Zartner [:sebo]]

So I think what I am pointing out here is that the flag in 127.0b4 is not working as in 128.0a1

Yes, that's expected, because bug 1896047 (exposing it to the accessibility tree) landed in 128.

Sebastian

Comment 36

[Dave Letorey]

Related issues and pull requests

• Content PR
• BCD PR
• Firefox Release Note PR