Alice: Was just chatting with Sangwhan in Slack. I filed this review, so it sounds good to me, of course. Sangwhan had some good points. I think it's OK the way it is. This went through quite a bit of discussion in CSS WG. The proposal is to, in a content property you can have a trailing slash following by a string, that will be treated as the alt text for the content where it at applies. Could be an element or a pseudo element, but with different rules. Sangwhan was proposing that wrapping the alt text in alt() would make it more readable; like James Craig's proposal.

Sangwhan: My feedback would be as somebody who inherited code. Not obvious what it does with the / syntax; alt() would be much more obvious. James Craig raised a background compatibility issue. Peter, were you involved?

Peter: nothing significant to add

Dan: I haven't been involved in this work. Coming into it... haven't been involved in the review. I'm sure it's been discussed already. Doesn't this break the model where we have separation of content and presentation?

Alice: This is the fourth time I've had this conversation.

Dan: Maybe a couple sentences in the TAG review / minutes?

Alice: What I wrote: Anne filed a meta-issue about separation of style and content. I think it's a false dichotomy that accessibility tree, find-in-page, etc. [PASTE THIS IN LATER]

Alice: There's another issue on AOM... looking at standardizing how accessibility tree gets built. DOM semantics aren't the same as accessibility semantics. We prioritize keeping the a11y tree semantics as close to the default UI semantics as we feasibly can, with caveats where certain things don't map onto the AT paradigm. DOM semantics can provide good signal to intended semantics

Dan: [back to the order of constituents] the needs of the user outweigh ideological purity

David: separation was broken when content was created. (Was intended for limited use.)

Sangwhan: The unfortunate reality is that there is a lot of content out there that uses this, which isn't accessible. This is a bug fix for that.

Dan: so are we done?

Alice: Sangwhan, Do you want to leave your feedback? I agree that alt() syntax would look nicer. My inclination would be to take that back to CSS WG and see what they say.

Sangwhan: I think I should just at least write formal feedback on this, and then I'll do that.

Dan: close issue, or pending external feedback?

Sangwhan: I'll mark it pending after I write the content.

Alice: pending feedback from whom, CSS Working Group?

Sangwhan: yes

Dan: I'll set milestone to face-to-face.

---

Lukasz: Question about alternative text for accessibility. If it's intended for screenreaders if no image is being displayed, would you consider the image still be downloaded?

Alice:

Lukasz: Is it just a matter of display and the content is being downloaded regardless? It's a text to replace the image if one is using screenreader.

Alice: Your Concern about checking whether the image has been downloaded or not?

Lukasz: Is there established practice here that you're aware of?

Alice: In Chrome, typically, running assistive technology doesn't have any impact on whether images are downloaded or not. You could (if we still have a setting) turn off download of images, but we don't have any branching for how the page is rendered. The only thing that branches is whether we compute the a11y tree.

Lukasz: If someone wants to optimize things for screenreaders. If someone optimizes away then someone can see that user is using screenreader. Maybe spec should have a tip that this shouldn't be the case.

Alice: My hesitation is that most UAs would work this way anyway. If someone is using assistive technology we don't know why they're using it. They might see the screen but be using the accessibility infrastructure to run an input device. And there are screenreader users who are sighted as well; they might be able to see the image but not be able to read text well. Most user agents would be building for those use cases so there wouldn't be a risk that they would try to optimize downloads like that.

Lukasz: If this is so complex, how does the screenreader decide when to ... never mind about that?

Lukasz: Should I write a comment in the github and ask about it?

Alice: Sure... worst case we can reply on the github issue to explain the situation in case someone else comes across it.

Sangwhan: I don't think this particular issue is affected.

Alice: We can have this discussion in the github issue so it can be captured

Alice: last thing was - comment from Amelia - some questions from Sangwhan about alternatives considered. There was a proposal early on about wrapping the string in an alt function which would make the purpose more obvious. Amelia pointed out that it's noop function which is weird. And came back to this issue - which risks content and alt getting out of sync... I asked Sangwhan if he'd be OK closing it, he said OK.

Peter: we're ready to close this.

Dan: Sangwhan should close it because he's been active on the issue [and alice has a conflict of interest