[wp-trac] [WordPress Trac] #37486: Make emojis accessible

[WordPress Trac]

#37486: Make emojis accessible
-----------------------------+--------------------------------------------
 Reporter:  afercia          |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Emoji            |     Version:  4.2
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui, accessibility, javascript
-----------------------------+--------------------------------------------

Comment (by pento):

 I've been thinking about this a little bit, and I think I have a direction
 worth investigating.

 * First, change the emoji element from an `img` to an `object`. This
 allows the SVG to interact with the embedding window. (The CDN currently
 doesn't allow embedding this way due to `X-Frame-Options`, but that can be
 fixed.) In the mean time, [https://pento.net/wp-content/uploads/1f3f3
 -fe0f-200d-1f308.svg here's an SVG] with the below script added, and no `X
 -Frame-Origins` restrictions.
 * Modify all of the SVGs to add a little bit of JavaScript. Something
 like:

 {{{
 <script type="text/javascript">
     window.parent.postMessage( { description: 'Rainbow flag', emoji:
 '1f3f3-fe0f-200d-1f308.svg' }, '*' );
 </script>
 }}}

 * Listen for this message in `wp-emoji.js`:

 {{{
 window.addEventListener( 'message', descriptionListener, false ):
 function descriptionListener( event ) {
     // Check that the message is coming from the CDN, and is correctly
 formatted.

     // Find all emoji elements that match event.data.emoji

     emojiEl.setAttribute( 'title', event.data.description );
     emojiEl.setAttribute( 'aria-label', 'Emoji: ' + event.data.description
 );
 }
 }}}

 This idea has several weaknesses:

 * It only works for SVG embeds, not PNG embeds. That excludes IE 8 and
 earlier.
 * To be properly translatable, we'd need to have different files for each
 language. It's not practical to update a single SVG file each time a new
 translation is added, due to the way the CDN works. Effectively, we'd have
 `1f3f3-fe0f-200d-1f308.en_AU.svg`, `1f3f3-fe0f-200d-1f308.it_IT.svg`, etc.
 I'm not sure whether we'd load emoji by site language or user client
 language, but that's an easy argument to have. :-)
 * It updates the DOM twice - once to add the emoji image, once to add the
 `aria-label`. I don't know how this affects screen readers.
 * Adding the `title` attribute doesn't cause a hover tooltip on `object`
 elements. I don't know how the `aria-label` behaves.
 * I don't know if this would be accepted by the upstream Twemoji project.
 It's unlikely that we'd need to change `twemoji.js`, so the primary
 concern is additional maintenance when emoji need to be updated - we'd
 need a script to add the `<script>` to all of them. Also, Twitter may not
 share their translations, so we may need to add all of the strings to
 GlotPress.

 Finally, here are some things that don't work, while I was experimenting:

 * Embedding as an `img`. The SVG can't send the message.
 * Accessing the SVG DOM from the parent window, so that we don't need to
 do the `postMessage`. Cross Domain Origin restrictions.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37486#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform