1281158 - Implement alternative text for 'content' property

Status: NEW

(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