[Umbrella] a11yhelp dialog needs attention

[Olek Nowodziński]

There are several things concerning the dialog that should be investigated/fixed/re-factorized:

1. Keyboard button labels are not consistent

   Editor Context Menu Press Shift+Ctrl+F10 or APPLICATION KEY to open context-menu. Then move to next menu option with TAB or DOWN ARROW. Move to previous option with SHIFT+TAB or UP ARROW. Press SPACE or ENTER to select the menu option. [...]

This is because some labels are hard-coded (upper case) and some are generated from langfiles (lower case). #11196 allowed translation of keys and we should take advantage of that feature. All hard-coded labels must be converted into dynamic ones.

2. We must verify whether help strings still match editor features. Some of them may be outdated/irrelevant/misleading. If necessary, some new ones should be written.

3. Some instructions are too complicated, some are unclear, e.g. lots of translators do not understand the MagicLine-related texts so we should revise the contents overall.

4. We must investigate a11y aspect of the dialog, e.g. compatibility with screen readers (JAWS). Perhaps <kbd> tags would be suitable here and there.

---

Related tickets we could also take into consideration:

• #8490: Plugins should extend a11yhelp to make the dialog dynamic and (build/editor)-dependent. At the moment a11yhelp creates a delusion that some features are enabled while, in fact, the plugins to which they belong are not even loaded.
• #9638: "Press ALT 0 for help" iframe voice label makes no sense when a11yhelp is not loaded (i.e. basic build).
• #10929: Spelling Mistakes on Accessibility Instructions dialog.

[Piotrek Koszuliński]

We'll not work on entire problem in upcoming releases, so I'm removing milestone. We can have its parts handled though, but separate tickets are needed.