Unexpected characters appear in Microsoft Edge's web pages when UIA support for Microsoft Edge is enabled in the advanced settings panel

[cary-rowen]

Steps to reproduce:

For example this settings page: edge://settings/appearance

Use the left and right arrows to navigate the characters and you will find unexpected characters.

Actual behavior:

Contains an unexpected character before each checkbox: 65532, 0 x f f f c

Expected behavior:

Does not contain the unexpected character, as in Google Chrome.

NVDA logs, crash dumps and other attachments:

log.txt

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2022.3Beta2

Windows version:

Windows 10 21H2 (x64) build 19044.1889

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

MS Edge: 104.0.1293.54

Other information about your system:

None

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

None

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

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[seanbudd]

Has this reported to Microsoft Edge developers? You can do this via the feedback mechanism

[seanbudd]

We can confirm that we can reproduce this on the "like"/"dislike" button in English with UIA enabled and Edge.

In English it only reports when pressing numpad2/NVDA+. 3 times. We note that in Chinese the Object Replacement Character is in the symbols dictionary. This is not the case for other languages including English, which is why this character is not reported in English. It is instead reported as space.

[feerrenrut]

This button is reported in NVDA as (when UIA for Edge is enabled):

Are you satisfied with the overall browser appearance? grouping like grouping like grouping button not checked like space

The reporting is more concise without UIA.

[cary-rowen]

@seanbudd

Has this reported to Microsoft Edge developers?

No, I haven't done it yet, I will if I have to.

[cary-rowen]

We note that in Chinese the Object Replacement Character is in the symbols dictionary. This is not the case for other languages including English, which is why this character is not reported in English. It is instead reported as space.

Yes, this character seems to appear quite often in the Chinese context, so the Chinese localization team added it to the symbols dictionary.

[cary-rowen]

@feerrenrut yes i admit it is very verbose

[cary-rowen]

as a temporary solution:

Set the level of the object substitution symbol to all,and instruct it to always send to the synth.

[seanbudd]

No, I haven't done it yet, I will if I have to.

@cary-rowen - no need, this is probably a problem with NVDA

[Adriani90]

@cary-rowen out of interest, in which context is this symbol used in chinese language?

[cary-rowen]

@Adriani90 There is no usage scenario for this symbol in Chinese expressions.

[Adriani90]

So can this symbol be removed from the chinese symbols file?Von meinem iPhone gesendetAm 05.04.2023 um 03:33 schrieb Rowen @.***>: @Adriani90 There is no usage scenario for this symbol in Chinese expressions.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[cary-rowen]

Cannot be deleted. Although it is rarely used in the written Chinese language, I have noticed that some instant messaging software uses it as a placeholder.

[Adriani90]

But is that placeholder important for the user? Does it transmit important information to the user? It would be very much appreciated if you can elaborate more on the use case for that symbol. Thanks.Von meinem iPhone gesendetAm 05.04.2023 um 09:39 schrieb Rowen @.***>: Cannot be deleted. Although it is rarely used in the written Chinese language, I have noticed that some instant messaging software uses it as a placeholder.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[cary-rowen]

Although I can illustrate a practical use case for this placeholder, I believe it is simply not practical to resolve this issue by removing the symbol. And removing this from the localization symbol file doesn't mean the user can't perceive it, the user will just be confused why there is a silent symbol.

Here's my clarification: In some instant messaging software in China (such as WeChat), users can copy a file in the explorer, paste it in the conversation dialog,and this symbol is placed in the message input box before the user clicks 'send' button. If NVDA can sense the presence of this symbol the user will know that the file has not been sent.

In the end, I think our discussion has gradually deviated from the essence of this issue. Do you represent NV Access to check the validity of these issues, and if the answer is no, to avoid confusion, please make this issue easier to investigate, please?

[Adriani90]

@cary-rowen thanks for your argumentation. No the discussion has not derived at all, it helps alot to understand the arguments and reasons for the expected user experience even if we talk about a small symbol. I didn't say at any moment that deleting this symbol from the translation would completely solve this issue. However, reporting nothing on a useless symbol is in my opinion better than reporting the useless symbol everytime which decreases efficiency while reading. I am sure no user wants to have all the unicode symbols reported when NVDA speaks.

However, according to your argumentation I totally understand the use case of this symbol.

[cary-rowen]

This symbol is currently only reported when moving the cursor in the Chinese environment. Thank you for your interest.

[Adriani90]

One could also argument as follows: hearing silence while moving the carret to this symbol does also mean there is something in the edit field, in your example an attached file. The question is, what is the prefered option for the user? To hear silence on this symbol? Or to hear the symbol itself?

Note that in the edit field, if there is no content in it, NVDA reports "blank" when using arrow keys to navigate. So silence on the symbol would also mean the carret moved to a symbol, but might be confusing for new users I guess.

[cary-rowen]

By default the user hears "对象替换符". So far this user experience is good, thanks!

[Adriani90]

Ok then it seems NVDA needs to ignore some use cases of reporting this symbol like in Edge which are exposed via UIA, but without touching other potential situations where this could be useful to hear.

for me it is not clear on which criterias the UIA Accessibility API relies when exposing this symbol to the screen reader.

[CyrilleB79]

Ok then it seems NVDA needs to ignore some use cases of reporting this symbol like in Edge which are exposed via UIA, but without touching other potential situations where this could be useful to hear.

for me it is not clear on which criterias the UIA Accessibility API relies when exposing this symbol to the screen reader.

Yes, that's probably the main question: why are these character exposed through accessibility API in this page? And should they be?

If they have no use and do not correspond to any visual equivalent, it would be worth reporting this issue to Microsoft.

Of course, saying that the issue does not occur with Narrator (if it is the case) is not a valid objection since NVDA has probably more capability to report or not characters and symbols.

[Adriani90]

Regarding the specific 0 x f f f c object replacement character, I found an interesting discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=1002910

So since this character is a displayable character as per Unicode definition, the accessibility APIs will always expose it. Probably UIA exposes it differently than IAccessible. It might be also a web authoring error if the text encoding or font used for the website does not support certain characters. I think this character is very often displayed depending on the device, language or text font you are using,.

So I think it is a question whether screen readers should render this character in their virtual documents or not? I can imagine that blind web or GUI designers would need this as a backup to check whether certain characters or formating is rendered correctly within a data stream.

There is also the 0XFFFD character which indeed is also a replacement character but it makes sense to display it, see this Wikipedia article for more details: https://en.wikipedia.org/wiki/Specials_(Unicode_block)

I wonder if it makes sense at all to add a certain short name or so for this character to the symbols.dic file? In general these special characters are spoken as "obj" in Unicode.

The drawback of leaving with the situation as it is now is that in some cases NVDA renders these characters on their own line in the virtual document in browse mode. Probably because it is a separate child object and again defined as a fieldnode in the NVDA helper.

So I see two things we could do here:

1. Add "obj" as the short name for 0xFFFC character in the symbols.dic file with symbol level "all"
2. Change the behavior in the virtual document to solve the case that this character is rendered on its own line when using browse mode with UIA enabled.

[Adriani90]

cc: @tomaszw, @@aursulis, thank you very much for your recent contributions to NVDA and adding support for the HP browser. This is really appreciated and will have a signifikant positive impact on users using UIA for browsers.

Here is an issue impacting users when using UIA and browse mode, replacement characters are displayed on their own line and this makes browse mode navigation line by line quite inefficient. This will impact HP browser as well. See https://github.com/nvaccess/nvda/issues/14013#issuecomment-2016463278 for more details.