From the external test and review of the test results I list the priority below. Some of the issues need to be reproduced for full understanding. We should open subtasks where appropiate. To have a better orientation I think we should keep the general prioritization in mind and work use case by use case.

1. Every interactive element has to be reachable by keyboard
2. Tables need to work with TAB focus and then arrow button navigation
3. Static contents should always be read to the user. (There I think esp. about the result dialogs)
4. Every button needs a text or tooltip
5. Every form entry needs a buddy for a description
6. All popups should be readable by the screenreader. Especially after clicking on info buttons.
7. Focus orders should be checked to be logic in the workflow
8. Keyboard navigation should follow the visiual order (also tab order related)
9. Invisible buttons may not be included in the tab order
10. Windows-Contrast settings should work and increase visibility of information. This can be tested on Linux as a first step.
11. Redundant information should be avioded (we do this afaik)
12. Row and Column headers somehow do not work properly with screen readers.
13. It should be possible to leave all text entry fields with either ESC or Strg+Tab in cases where only tab is not enough. e.g. in the Notepad
14. Some contents are only visible through mouse hover. I think this might be where tooltips are opened directly by code and when they are not connected to a widget element. Probably most prominently in the key list / key selection
15. Keyboard focus should always be visible through an indicator
16. Information should never only be transfered by color. E.g. validity. ( I do not think that we do this currently, but we need to check)
17. Contrasts between background and foreground is too low. Probably also in the result widgets. I can agree with that. The contrast should be 3:1 for large fonts and 4.5:1 for small fonts
18. All contents need to be visible with 400% zoom. So under a magnifier.
19. Additional contents should not hide automatically when the mouse is moved over it.
20. Error messages need to be visible. This is probably mostly a problem when we write an error below an input field. E.g. in the newcertificate wizard.
21. Help texts, and documentation especially lists in help texts need to be screenreader compatible.
22. All interactive elements should have appropiate roles

For our internal tests this boils down to testing:

• with keyboard only
• for people using a screenreader
• with 400 % magnification
• with high contrast color scheme
• with inverted color scheme

A further thought is that we need in general more AccessibleDescription texts like "please enter name and email" on a dialog where for us it is obvious that name and email are input fields. I would like to test this by giving a user with no knowledge of the software the quickguide our customer gave or our own handout without screenshots and a set of public keys with the tasks to encrypt a file for herself and for one specific other recipient.

For the next release T5842 (so with a higher priority) I have picked

T5841
T5832
T5845

I think having the keylist and keyselection when encrypting improved is the best way to help current users of the software who might already have received help from a collegue to import and have a list of certified certificates available.

2. Tables need to work with TAB focus and then arrow button navigation

I have checked all tables, list views and other UI elements that work on an item model (i.e. where we use setModel) and all usage of QTreeView/Widget. Some tables are not yet accessible:

• T6099: Kleopatra: Make checksum verification accessible
• T6101: Kleopatra: Make self-test accessible
• T6102: Kleopatra: Make Certifications dialog accessible
• T6103: Kleopatra: Make key selection dialog accessible
• T6104: Kleopatra: Make Subkeys Details dialog accessible

The welcomewidget has some problems:

The big black frame is too much of an optical highlight in my opinion. Can we remove that with a stylesheet or so?

Similarly in the result list:

Also in the welcomewidget if you tab and then select the new key pair, hitting enter to start keypair creation does not work. And selecting it manually opens the wizard and not the key pair creation dialog.

I know that the black frame looks bad. (It looks a bit better with Breeze.) The problem is that accessibility requires a visual indication of the keyboard input focus (see second recommendation for issue [3] in the report).

Because it doesn't look good, but it is required for full accessibility, I have considered adding a configuration option to enable/disable extended accessibility.

Please add a subtask for the other problems in the welcome widget or add the information to the corresponding existing subtask (if there is one). This task here really only serves as Klammer-Ticket for the actual work items.

In T5824#160925, @ikloecker wrote:

Because it doesn't look good, but it is required for full accessibility, I have considered adding a configuration option to enable/disable extended accessibility.

Maybe. I am not really a fan of this. That should be only last resort. I mean ok we require a visual indication which text is highlighted. Maybe a bevel to make it a bit more 3d or a thin white line around the text?

As this is general how we indicate selected text the discussion makes imo sense here. For the welcomewidget I will add something in the certificate generation task.

I'm using QFocusFrame for the visual indication. Qt uses QFocusFrame only with the MacStyle and there it probably looks much better. Breeze also uses it (inspired by the MacStyle).

Using QFocusFrame is the only way I found to do a visual focus indication without writing an own QStyle or doing the drawing on my own circumventing the style. I suppose, I'll have to look into creating a Windows style where the QFocusFrame looks better or creating my own QFocusFrame derivative with uses some other style primitives for drawing the frame.