Hi

seems basic question but I think css is for style. if you need to add alt text (for AT or so) to that image, it's a content not for style. then you can of course use <img> instead. is there any reason don't let them use img if you think its necessary to add alt text for AT or so ?

True, but authors can and do use css generated content to supply semantic information which should have an alt text to make it available to AT.

On Sat, Mar 23, 2019 at 2:06 AM Jxck notifications@github.com wrote:

Hi

seems basic question but I think css is for style. if you need to add alt text (for AT or so) to that image, it's a content not for style. then you can of course use <img> instead. is there any reason don't let them use img if you think its necessary to add alt text for AT or so ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/351#issuecomment-475853646, or mute the thread https://github.com/notifications/unsubscribe-auth/AikYipPWP_tWjabYZ2MyGK2PVEwyhioyks5vZe6GgaJpZM4bprE9 .

This is an interesting tipping point. There's been all this advocacy that CSS is supposed to be optional and HTML should be readable without it, but this would go right against that.

Do we have reason to believe that developers abusing CSS for adding content would use this feature? That is, if they are not informed about CSS being optional, why would they be informed about this?

@annevk What do you mean, abusing CSS for adding content? Could you point to an example?

The explainer had a couple of examples of how we expect this feature to be used.

E.g., dl.domintro::before { content: 'For web developers (non-normative)'; } from https://resources.whatwg.org/spec.css is misuse of CSS I'd say, going from the assumption that CSS is optional or could have been completely overridden by the user.

@robdodson had some good responses from developers on when they'd want to use this feature, from his tweet here: https://twitter.com/rob_dodson/status/1090060058224803840

Your objection seems to be more about :content in general, which as @dot-miniscule pointed out is already used in this way. This feature doesn't change that; it just gives authors a way to change its expression in the accessibility tree, just as they can for any other DOM content. I'd really prefer not to re-litigate :content in this thread.

Had a chat offline with @annevk and he clarified that it was less an objection and more of a philosophical query, which led to https://github.com/w3c/csswg-drafts/issues/3778

In terms of this specific case, the cat is really out of the bag in terms of :content being exposed in the accessibility tree, and the responses to Rob's tweet shows that authors are looking for a way to fine-tune that content.

I think so about cat is out of the bag really. but this spec justifies the means of contents is really a contents not only for style.

for example, if TA cares Content in HTML, ignores Style (its not wired for me), contents author can recognize it's bad for adding Content in CSS content and we also enlighte them to sparate Style and Content. but once this spec will standardized, put Contents in Style is justified by annotating with alt. it's end up with TA author MUST parse all css if they wanna assist accessing user to Content. and User can't disable CSS (like Reader Mode in these days) because of CSS has not only Style but also Content too. (I don't talk about Reader Mode implementation detail).

but If you says "That is Current Web and support that by Standard Spec", I can say nothing :(

The accessibility tree already depends on CSS, and has done for a long while; for example, display: none will cause an Element to be excluded from the accessibility tree (because it's not rendered, so assumed to be currently not relevant to the user).

Pseudo-elements with :content are also already exposed in the accessibility tree. This feature will allow authors to fine-tune that process, by either marking them as not relevant for accessibility (by providing an empty string as the text alternative), or by providing a more useful string.

Hi,

Looks like a useful addition for some. Following telecon discussion I've got a question. I'm not fully aware how all assistive technologies work (i.e. how the mode of operation functions). But I'm wondering whether if assistive tech is in use and enabled to work, browsers might (by default) choose to stop downloading the images, deferring to displaying the text only (i.e. a kind of optimization)? In that case it would potentially reveal that someone is using assistive tech.

If there is a hypothetical scenario of someone implementing this to work this way (when displaying alternative text, don't download the image), I'd consider if adding a tip/note explaining the potential risk wouldn't be a good idea. But as I likely do not have the required expertise in ATs, I am simply asking.

@lknik Thanks for the comment!

I don't think this is ever likely to be a danger, as UAs have no way of knowing whether a user may or may not be able to see the image based on whether they are using a piece of software which accesses accessibility APIs. And even if we could tell that (which we can't), we wouldn't know whether they were likely sharing their screen with someone else at any given moment.

The use of accessibility APIs really seems like too weak a signal to use for such a drastic measure, compared to something like a user preference not to download images.

So I don't think it's worth warning against this case, though I do understand the concern.

We discussed this in today's call, and the use cases are valid. There is obviously the philosophical question of separation of style and markup, and we are generally in agreement that putting content in style is suboptimal. That said, as unshipping content is not really an option here, we would like to see this feature itself move forward.

Two points of feedback on the state of the spec:

1. Backwards compatibility: This has been raised, but leaving this as it still is a valid issue. As long as a duplicate declaration for incompatible browsers is a reliably usable mechanism, we don't feel strongly against this. (On a side note, it being unergonomic could potentially promote content authors to do it in markup rather than content. Or at least one can hope.)
2. Lack of a syntactic signifier of the purpose: This is a larger concern. In the current proposal, it is not obvious what the alt text declared in style is for. From a content author's perspective, the purpose of the / "something" can be interpreted liberally (and is not obvious) on what purpose it serves; and this is concerning.

I would really like to see point 2 addressed. Without seeing this particular syntax (or looking up the relevant specs or MDN documentation) a content author who has inherited a stylesheet without being educated on the subject matter it wouldn't be obvious what purpose this serves. (and might end up deleting it, breaking accessibility)

Wrapping it around alt() would make the purpose a lot more obvious. I believe this has been proposed within the CSSWG, and we'd like to see this revisited if possible.

Unrelated to TAG feedback, one question is whether or not it would be useful for the alt to be inheritable, but only change out the image. I'm suspecting the use cases would be rather slim but this is just out of curiosity.

Forgot to mention @csswg-drafts. I'm not quite sure where to file the issues though, is it supposed to be here? https://github.com/w3c/csswg-drafts/labels/css-content-3

(Edited: Seems like @csswg-drafts is not a GH user. Hmm.)

@dot-miniscule filed the issue on csswg-drafts: https://github.com/w3c/csswg-drafts/issues/3899

One relevant response, from @AmeliaBR:

[F]unctions in CSS serve to transform data, not to label it. Most functions can be used in many different properties, creating a new data type.

The alt() wrapper might help a developer understand unfamiliar code, but once they are familiar with it, it will just become extra characters to type.

(And quite frankly, the main obstacle to developer familiarity right now is lack of browser support!)

one question is whether or not it would be useful for the alt to be inheritable, but only change out the image.

The original proposal, to have a separate alt property, would have supported this (and as a side effect, would have avoided backwards compatibility issues):

.warning::before {
  content: url(scorpion.svg);
  alt: "warning, ";
}
:lang(fr).warning::before {
  alt: "attention, ";
}
[data-theme=simple] .warning::before {
  content: "⚠";
}

But it was decided that this was an anti-pattern: the risk of content and alt text getting out of sync was considered more significant than the benefit of sometimes being able to apply the same alt text for different images or different alt text for the same images. As developers update their CSS, they could override content with different selectors, but forget to override alt to match.

See discussion here (and other replies in this thread), which seem to be the original source of the proposal to combine the alt text into the content property: https://lists.w3.org/Archives/Public/www-style/2014Nov/0046.html

There is a follow-up explanation in this thread: https://lists.w3.org/Archives/Public/www-style/2016May/0103.html

I'm not 100% convinced that this justifies the loss of flexibility, but I agree that there are limitations either way. And with the current spec, if an author needs the same alt/image for multiple content declarations, it can be coordinated using CSS variables.

We've discussed this a couple calls ago, and concluded it is safe to close. Thanks for bringing this to our attention, and let us know how the content authors react to this when it ships.