lucus1's profile

111 Messages

 • 

13.8K Points

Mon, Oct 20, 2014 12:49 AM

Accessible Emoji/Emoticon Labels for visually-impaired users of the message boards?

In a reply in the "Old Smileys Are Back" thread on the IMDb Information board, "Purk" mentioned an accessibility issue experienced by visually-impaired users who use "screen-reader" software (which uses speech synthesis to speak the text and describe the contents of a page):

The apparent problem is that most screen-reader software may not speak the names of emoji or emoticons where they appear in posted messages.

(The same is true of the emoji/emoticon "menu". But I assume that it might be more difficult to provide screen-reader accessibility for the "menu" in its current design. That could be a matter for future discussion. For now, I'll only ask IMDb to consider providing screen-reader accessibility for emoji/emoticons in the content of posted messages.)


Here's one suggestion for a simple experimental partial workaround (not a complete solution):

Could IMDb set the "aria-label" attribute to the name of the emoticon or emoji (in exactly the same way that IMDb currently sets the "title" attribute) on a containing HTML span element?

I've just tried a quick test. I think the suggested use of the "aria-label" attribute might allow an emoticon or emoji's label to be spoken by the current version of the free "NVDA" screen-reader for Windows (http://nvaccess.org).

Unfortunately, that simple workaround currently might not work with some other screen-readers, such as the other one I briefly tested in Windows, "JAWS".


Some other known workarounds are unfortunately not so simple.
One controversial approach would involve creating additional elements containing label text intended for screen-readers, and using CSS trickery to conceal those elements visually (e.g., variations of the "off-screen" technique or the "clip" technique). This might have a chance to work with various screen-readers. Unfortunately, such methods can be cumbersome, requiring careful implementation and thorough testing to reduce risks of browser-dependent issues etc....

I'm not an expert on accessibility techniques, and I'm not up on the latest discussions about them. There may be other possible solutions that I don't know about.

This conversation is no longer open for comments or replies and is no longer visible to community members.

Responses

No Responses!