Page MenuHome GnuPG

Kleopatra: Full accessibility support
Open, NormalPublic


This is a followup of T5535 in which we improved accessibility for symmetric file encryption. The test for this was to encrypt and decrypt files with passwords and password generation with closed eyes.

We now have an accessibility report for other parts of Kleopatra. Due to our recent extension of the user base we need to improve accessibility across the board. New features should always be implemented with accessibility in mind. E.g. decent tab orders, shortcuts and hotkeys, descriptions on buttons instead of icons and if icons are used a tooltip which a screenreader can tell.
Also we should not use only colors or other visual indicators for status.

For more details we have the accessibility report. This issue should serve as a parent for smaller tasks and shall be closed after we do another external review of the accessibility, once we as developers think that we have done everything reasonable to make our complex software accessible for everyone.

I am setting a due date for this at the start of september so that we can contract an external report in september.


Due Date
Sep 1 2022, 12:00 AM

Related Objects


Event Timeline

aheinecke triaged this task as Normal priority.Feb 10 2022, 1:58 PM
aheinecke created this task.

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


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.

ikloecker changed the status of subtask T5841: Kleopatra: Make keylist / keytreeview accessible from Open to Testing.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Mar 28 2022, 1:41 PM
  1. 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:

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.

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.