works in vsd3.3.3, tested with VS-Desktop-3.3.90.8-Beta

Fixed and backported for VSD 3.4

Solved by focusing the result message after the notepad operation is complete. I think that's an acceptable compromise for ensuring that users of assistive tools are informed about the result even if the focus is moved to a different UI element (which, in general, should be avoided because users can get lost).

The gold rule of tab order is that tab order follows the usual reading direction, i.e. line by line from left to right. If you press Enter after entering the password in the first input field then the focus should jump to the second input field.

Looks good to me on gpg4win-5.0.0-beta357 @ win10:

The fix should be available in gpg4win-5.0.0-beta350.

Ideally, this will be solved for VSD 3.4.

not sure if this really is an issue, maybe for a person proficient with a a screenreader the behavior ist ok, after the fix of the show/hide button is done?

Other duplicate texts:

• Enter some characters for Password and some other characters for Repeat and press Return.
• Message box pops up to inform user that the two entered texts don't match. NVDA reads

does not match - try again  dialog
OK  button  Enter (not audible)
does not match - try again  dialog

This has been fixed in pinentry-qt5 (which is used by VSD 3.x).

tested with Gpg4win-5.0.0-beta345

Done.

Backported for VSD 3.4

not mentioned in the test for v3.1.26, and checksums are no important part of the software

For simplicity (and because I think entering tab characters isn't really essential for the notepad) I decided to go with the first solution.

I guess, that's ok then, moving this to done.

In T7594#202471, @timegrid wrote:

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).