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

WordPress Trac noreply at wordpress.org
Fri Jun 28 11:51:09 UTC 2019


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

Comment (by afercia):

 Thanks for the patch!

 **Testing on macOS Mojave 10.14.5**
 Safari 12.1.1
 VoiceOver 9

 [[Image()]]

 First thing to note, Safari and VoiceOver now announce the "carrot" emoji.
 Three years ago they didn't. Progress! :) This seems to confirm that with
 operating systems / browsers updates, new emoji versions are natively
 supported and recognized.

 With the patch applied, VoiceOver announces "image" instead of "group",
 which is a welcomed improvement. The `aria-label` doesn't appear to make a
 difference. More on this later.

 Worth noting the actual behavior varies depending on the command used to
 read content, for example:

 Read All: Control + Option + A
 reads the emojis, treating them as images

 Read Paragraph: Control + Option + P
 ignores the emojis and reads just the text: "Hello, this is a and this is
 a"``. Note: this is the standard behavior also with inline images.

 Read Sentence: Control + Option + S
 Same.

 Read Line: Control + Option + L
 Same.

 Navigating content with Control + Option + Right (and Left) arrows:
 reads the emojis, treating them as images


 **Testing on Windows 10 Pro – version 1803 build 17134.829**
 Chrome 75.0.3770.100
 Firefox 67.0.4
 Internet Explorer 11
 JAWS 2018
 NVDA 2019.1.1

 **Before the patch:**

 - Firefox JAWS: "Hello, this is a and this is a"
 - Chrome JAWS: "Hello, this is a and this is a"
 - IE 11 JAWS: "Hello, this is a graphic slightly smiling face and this is
 a graphic"
   note: doesn't read automatically the whole paragraph though and requires
 to use arrows to navigate through content

 So it appears JAWS 2018 doesn't announce the emojis with modern browsers
 and surprisingly announce at least the smile with an old browser like IE
 11, probably because it fallbacks to scraping the DOM for IE 11?

 - Firefox NVDA: "Hello, this is graphic slightly smiling face and this is
 a graphic carrot"
 - Chrome NVDA: "Hello, this is graphic slightly smiling face and this is a
 graphic carrot"
 - IE11 NVDA: "Hello, this is graphic slightly smiling face and this is a
 graphic carrot"

 NVDA works very well with all the tested browsers.

 **With the patch applied:**

 - JAWS with all the 3 browsers: no difference
 - NVDA with all the 3 browsers: no difference

 Looking at the Chrome dev tools > Accessibility tab helps to understand
 why the `aria-label` makes no difference:

 Before the patch, the accessible name of the emoji come from the alt
 attribute (which by the way contains the emoji so it relies on the fact
 the emoji is recognized by the OS and browser):

 [[Image(http://cldup.com/kSsn_fzqxT.jpeg)]]

 After the patch, the accessible name comes from the `aria-label` which
 just overrides the alt attribute:

 [[Image(http://cldup.com/h134tOWlVU.jpeg)]]

 So it appears the aria-label is redundant and can be removed.

 Technically, also the ARIA role is redundant because `<img>` element have
 a native role of... image. However, it helps VoiceOver to correctly
 announce "image" instead of "group" and I'd lean towards keeping it. HTML
 validators may warn this role is redundant but it doesn't harm anything.

 Lastly, I do realize there are no realistic methods for further
 improvements, so far. However, I'd like to keep this ticket open to track
 the issue and future progress in OSes support. If no objections, I'd like
 to propose to make this ticket a blessed task.

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


More information about the wp-trac mailing list