[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