Intent to Prototype: Multi-argument alt text in CSS Generated Content
Daniel Clark
Contact emails
Explainer
None
Specification
https://www.w3.org/TR/css-content-3/#valdef-content---string--counter
Summary
The CSS content property allows developers to specify alternative text for accessibility with the following syntax:
.has-before-content::before { content: url("cat.jpg") / "A cute cat"; }
This functionality is already partially supported in Chromium (https://chromestatus.com/feature/4550056227110912) such that the alt text can be given by a single string. However, the spec allows the alt text to be given by an arbitrary number of arguments, which in addition to strings can be attr() functions or counters. For example:
.has-before-content::before { content: url("cat.jpg") / "Cute " attr(data-animal) " number " counter(animal-counter); }
This Intent is for the expansion of the Chromium implementation to support the full span of arguments permitted by the spec.
Blink component
Motivation
This will allow developers more flexibility in how they specify alt text for generated content, making it easier to build accessible web pages.
Additionally, this functionality is tested as part of the Interop2024 Accessibility focus area. Specifically, https://wpt.fyi/results/accname/name/comp_name_from_content.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility sub-tests "(button|heading|link) name from fallback content mixing attr() and strings with ::before and ::after"
Initial public proposal
None
TAG review
None. Omitting TAG review per the guidelines at https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/ since this is already specified in a CSSWG draft and shipped in WebKit.
TAG review status
Not applicable.
Risks
Interoperability and Compatibility
The new syntax will fail to parse in browser where it’s not supported, so until browser support is widespread, developers should include a preceding fallback line to specify the content:
.has-before-content::before {
content: url("cat.jpg"); /* Used if the following line doesn't parse */
content: url("cat.jpg") / "Cute " attr(data-animal) " number " counter(animal-counter);
}
This compat risk is not really new given the feature’s current state of partial support.
Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)
WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185)
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
The accessible text can be viewed in the accessibility tree via chrome://accessibility. DevTools will allow this part of the content property to be edited in the Style pane.
Is this feature fully tested by web-platform-tests?
https://wpt.fyi/results/css/css-content/parsing/content-valid.html
https://wpt.fyi/results/accname/name/comp_name_from_content.html (sub-tests "(button|heading|link) name from fallback content mixing attr() and strings with ::before and ::after")
Flag name on chrome://flags
None
Finch feature name
Non-finch justification
None
Requires code in //chrome?
False
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5168344402755584