The trouble is, I think, that typefaces vary so much that some could appear to have a strike through when they don't.
Or take for example the number 0 which sometimes has a fairly horizontal slash through it. Do you program the screen reader to check if the struck letter is a 0, and if so, consider it not to be struck? But... What if it actually is, and that typeface doesn't have a slashed 0?
Do you only check perfectly horizontal strikes? How thick? At which height in the type? How much overhead is it to parse all of this? etc.
This also requires rendering the document and inspecting the image with object detection, I would think? Someone correct me if I'm wrong, I'm only trying to imagine potential problems.
The issue is not with detecting the strike through. The issue is that the CSS of the hidden "not" element obviously makes the element invisible, but a screen reader still reads it.
Obviously, Apple is abusing that fact here in order to insert elements that only screen readers would see. Definitely feels like a hack.
There is a text-decoration: line-through csv styling available, which I would hope a screen reader would convey properly. Apple isn't using that here though, for whatever reason.
An AI could probably get pretty good at detecting and interpreting stuff like the ::after as a strikethrough. The general problem of extracting semantics from a hacked up html / css / js web page feels like it would require a human level AGI. There are a ton of ways to make text appear with a line through it, and in some cases it may not even have been intended as a strikethrough.
