Closed Bug 1281158 Opened 8 years ago Closed 2 months ago

Implement alternative text for 'content' property

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
127 Branch
Tracking Status
firefox127 --- fixed

People

(Reporter: sebo, Assigned: emilio)

References

(Blocks 3 open bugs, )

Details

(Keywords: dev-doc-complete, parity-chrome, parity-safari)

Attachments

(4 files)

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
Priority: -- → P3
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.
Depends on: 1483898

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

Severity: normal → S3

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.

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

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.

(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

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.

Flags: needinfo?(sebastianzartner)

(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

Flags: needinfo?(sebastianzartner)

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.

(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

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

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

Duplicate of this bug: 1818232
Blocks: 1871767

Safari doesn't currently support this feature.

Sebastian

Keywords: parity-safari

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

Ah, sorry! I missed that.

Sebastian

Keywords: parity-safari
Blocks: 1878355
Duplicate of this bug: 1884747
Duplicate of this bug: 1871767

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

Flags: needinfo?(emilio)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

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.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
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
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46167 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch
Regressions: 1895896
Duplicate of this bug: 1483898
Blocks: 1896047
Keywords: dev-doc-needed
Upstream PR merged by moz-wptsync-bot

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?

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.

(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.

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

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)

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

Related issues and pull requests

Blocks: 1899723
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: