Utext: Rich Unicode Documents
gwern.net
Utext: Rich Unicode Documents
1–10 of 11 posts
Re: Utext: Rich Unicode Documents
#2Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Re: Utext: Rich Unicode Documents
#3Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Sounds like a problem with the screen reader. If they are supposed to replace the part where the user interprets a glyph on the screen, then they should act like a human would and interpret something that looks like semicolon as a semicolon, even if it's a Greek question mark (excepting at the end of a Greek question).
(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.)
Re: Utext: Rich Unicode Documents
#4Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Sounds like a problem with the screen reader. If they are supposed to replace the part where the user interprets a glyph on the screen, then they should act like a human would and interpret something that looks like semicolon as a semicolon, even if it's a Greek question mark (excepting at the end of a Greek question). (Do any of them have an OCR layer? The context sensitivity might be more challenging, but probably…
[deleted]
Re: Utext: Rich Unicode Documents
#5Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Sounds like a problem with the screen reader. If they are supposed to replace the part where the user interprets a glyph on the screen, then they should act like a human would and interpret something that looks like semicolon as a semicolon, even if it's a Greek question mark (excepting at the end of a Greek question). (Do any of them have an OCR layer? The context sensitivity might be more challenging, but probably…
The problem is that use of unusual Unicode characters represents memes, there are constantly new ones and it would be hard for any screenreader to keep up with new stuff. And there are plenty of imaginative use of letters from Indian scripts, from hieroglyphics, etc. where the screenreader can’t be expected to recognize what is intended as easily as a human being would.
Re: Utext: Rich Unicode Documents
#6I can only counter with https://en.wikipedia.org/wiki/Ornament_and_Crime
Re: Utext: Rich Unicode Documents
#7Sounds like a nightmare when trying to copy-paste text ?
Re: Utext: Rich Unicode Documents
#8Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Sounds like a problem with the screen reader. If they are supposed to replace the part where the user interprets a glyph on the screen, then they should act like a human would and interpret something that looks like semicolon as a semicolon, even if it's a Greek question mark (excepting at the end of a Greek question). (Do any of them have an OCR layer? The context sensitivity might be more challenging, but probably…
It isn't (just) a problem of the screen reader.
This is hacking unicode to do things that unicode isn't supposed to try to do.
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.
Re: Utext: Rich Unicode Documents
#9I can only counter with https://en.wikipedia.org/wiki/Ornament_and_Crime
Considering that buildings inspired by Loos make me want to barf, I'll take that as a compliment.
Re: Utext: Rich Unicode Documents
#10Blind people reliant on screenreaders often complain about people using unusual Unicode characters to spice up their writing, since the screenreader can’t make sense of those characters or tries to pronounce them as in the language they were intended for. So, the approach toyed with here would be a veritable nightmare for those members of the community.
Unicode characters useful for typography don't come along that often, and many of the relevant characters here date back decades. So if screenreaders can't reliably ignore a character like SOFT HYPHEN which is older than many of the readers here, that's ultimately their fault.
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.