[croon]

> 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.

[wahnfrieden]

Unicode language prescriptivism... that’s a new one.

[croon]

That'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.

[maxerickson]

Yes, 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 \.