In any case, because a Utext starts & ends as a plain text file, there is no reason you have to throw away the source text serve readers only the compiled fancy Unicode text version; they can live happily in the same file. You can (and should for reasons I outline) serve both the original 'source' and the 'compiled' version, and you can be clever about using whitespace or control characters to signal inband which is which, allowing the user to choose with a trivial grep: https://gwern.net/utext#utext-format And so in practice I think it would be superior in accessibility than many things.
(Do any of them have an OCR layer? The context sensitivity might be more challenging, but probably can be specialised to common cases or LLM-magicked away.)
This is hacking unicode to do things that unicode isn't supposed to try to do.
<List> <Item> element ....
Tells me that this is a list of things.
Reusing a unicode thing that just happens to look like a dot doesn't give context to the screen reader. It doesn't see a fancy bullet point it sees U184638 'libyan double sigilled C' or what ever.
You're then relying on the hearer to know that U184638 looks like a fancy bullet point.
