nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

Does not read emojis in aria-label #14296

Open Leon-Lj opened 1 year ago

Leon-Lj commented 1 year ago

NVDA does not read emojis that are in aria-lable, it just skips them and reads the rest of the label. If aria-labelledby is used to link it to a section that contains a emoji, then it'll read it just fine.

Steps to reproduce:

  1. Create a html file with content:
    <!DOCTYPE html>
    <html lang="en-US">
    <head>
    <meta charset="utf-8" />
    <title>NVDA Emoji Test</title>
    </head>
    <body>
    <main>
    <div role="math" aria-label="🌻+2=6^{2}">
      🌻+2=6<sup>2
    </div>
    </main>
    </body>
    </html>
  2. Open the html file in Chrome
  3. Enter the main region
  4. Use arrow keys to read the math expression

    Actual behavior:

    +2=6^{2} It does not read the emoji (in the speech viewer it comes up as ??+2=6^{2} but that did not transfer when copied).

Expected behavior:

🌻+2=6^{2} It should read the emoji when in a aria-lable. If you mouse over the emoji it reads it just fine (producing 🌻+2=6 in the speech viewer), I assume that's because it then reads the content of the div rather than the label.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2022.3.1

Windows version:

10.0.18363 Build 18364

Name and version of other software in use when reproducing the issue:

Chrome 106.0.5249.119

Other questions

Does the issue still occur after restarting your computer?

Yes

If NVDA add-ons are disabled, is your problem still occurring?

No add-ons enabled.

michaelDCurran commented 1 year ago

Confirmed. I reproduced this with my NvDA log level set to input / output. After speaking the main landmark, it then tried to speak two 0xfffd characters. which I believe are Unicode placeholder characters. I think this may be a bug in NVDA where we have deliberately converted unknown / private use unicode characters into safe characters before explorting them via attributes in our internal xml representation of the content as it gets sent from the browser process to NVDA. this is most likely then NVDA being too broad with its checks. There should certainly be a valid way of storing imoji unicode characters in an xml attribute string. For anyone looking to fix this: Please refer to appendCharToXML in nvdaHelper/common/xml.h