@LeonarddeR I am sorry to say that ad least in Word 2010 it fixes nothing. I've looked at the developer info for the context menu items there and it is a complete mess

1. For some like copy name is copy, but description is copy (Ctrl+X)
2. for others Name and description are both empty, the shortcut is defined, and the name is in the child object of it.

I wonder if it wouldn't be better to stop using UIA for Word 2010 context menus all together.

2. for others Name and description are both empty, the shortcut is defined, and the name is in the child object of it.

This might be the reason why IAccessible.MenuItem uses displayText when the name is empty.

This is unfortunate.

I have pushed two new commits, one that uses the displayText as name when the name is empty, and one that adds the keyboardShortcut to the developer info. In the case where the shortcut is part of the description, could you say whether keyboardShortcut is empty, or does it contain exactly the same shortcut?

@LeonarddeR wrote:

I have pushed two new commits, one that uses the displayText as name when the name is empty,

Unfortunately the displayText in these cases is complete garbage, so it is even worse than before.

and one that adds the keyboardShortcut to the developer info. In the case where the shortcut is part > of the description, could you say whether keyboardShortcut is empty, or does it contain exactly the > same
shortcut?

They are completely different,, that is in case of copy The shortcut in the description is Ctrl+C and in the shortcut it is reported as k ad least in the polish version of Word.

@LeonarddeR What are your plans regarding this PR? I'd be nice to solve this before release of 2019.1.

I think for Office 2016, we probably should remove the description if it is equal to the name. However, for older versions of Office, it would be best if we didn't use UIA for these menus at all. That is very very tricky to do though, as this code affects a lot of things on the Ribbons as they use the same class names etc. We could perhaps borrow the code from the UIAByDefault branch that I had to specifically detect Office 2016, but for that to work you do need to specifically look for winword, outlook, excel or powerpoint executables. We might be missing some scenarios. An alternative for 2019.1 is to revert all the NetUI changes that came from the UIAInMSWordByDefault branch, but this will again break Outlook auto completes, and also quite a few other controls in the Ribbon in Office 2016.
Double speaking is annoying, but waying that up against controls not speaking at all, I'd always take double speaking. But if I understand this correctly, in Office 2010 it is worse as some menu items don't speak at all.

If these class names were only used in Office, then we could just detect the version and blacklist anything under 16.0. But these NetUI controls can be used in other parts of Windows.

... but this will again break Outlook auto completes

Note that for some users, using UIA for Outlook Auto completes regresses the behaviour. For me, the auto completes worked acceptably in the old situation, whereas now, they don't

I removed everything from this pr except for clearing the description when equal to name, as it initially was. We do not use the display text.

That is so strange that you get such different results. However, in that case, it sort of makes sense to simply back out all those changes for 2019.1. I'll look into this tomorrow. Perhaps I can selvage part of it... there were some controls in the MS Word ribbon which were not speaking at all.

I haven't experienced menu item which didn't speak some are reported very strangely though. From the end user perspective it is a regression without good reason For Office 2016 users it can be argued that they have double reporting but now autocomplete in Outlook works for them, but in 2010 it worked anyway, so they getting worse experience without any benefit.