4 ms·
> I think it is reasonable to expect a transcription service or screen reader to treat "¯_(ツ)_/¯" like it treats any other word. For a seeing person, there is
by croon 9y ago
> I think it is reasonable to expect a transcription service or screen reader to treat "¯_(ツ)_/¯" like it treats any other word.
For a seeing person, there is negligible difference between "¯_(ツ)_/¯" and "¯\_(ツ)_/¯".
For either a seeing or blind person there is negligible difference between "emoji" and "meoji".
We can all make up emojis on the spot that can only heuristically be decrypted by seeing them as an image, not reading them one character at a time.
Making up a new word is still just a sequence of characters, and can be understood by any medium, whether it's written, braille, audio, etc.
There's no reasonable way to transcript emojis other than a predefined database of them, which unicode already has.
- maxerickson 9y agoYes, my point is that a transcription service or screen reader will be well served by having a database containing symbol sequences like "¯\_(ツ)_/¯". And transcription services should certainly recognize "¯_(ツ)_/¯" as a failed attempt at "¯\_(ツ)_/¯". Screen readers probably should too. If they are sticking to whatever Unicode blesses they aren't serving their users well. Also, I read provost as talking about the art in general, including a correct shrug, so I replied in that context instead of spending time on the missing \.
- wahnfrieden 9y agoUnicode language prescriptivism... that’s a new one.
- croon 9y agoThat's not what I was suggesting. I was suggesting that the proposed solution would be nothing more than doing the same thing again, but as a transcription service. Unicode updates with new emojis too. Being more adaptive than that requires offloading the responsibility of readability to the writers. If I write a blog post featuring a unique ascii emoji I made up, I can't expect a third party to handle that for blind patrons, regardless if it's a transcription service or unicode.