如何确保 Python qt 应用程序在所有操作系统上都是屏幕可读的

Question

I am developing a text with Python and Qt that can be used by blind and visually impaired people. The text editor should be suitable for screen readers. I do tests with the screen readers NVDA (Windows) and Orca (Ubuntu).

Texts for screen readers should actually be saved in the "AccessibleDescription" property. The NVDA screen reader does not read the "AccessibleDescription" property. AccessibleName property only. The Orca screen reader reads the "AccessibleDescription" property.

Question: What can I do so that my application is screen-readable on all operating systems?

Answer 1

Short answer

Sadly, there's probably no magic solution here. The only reasonnable answer is just trying and testing a maximum of different combinations of OS, screen readers, GUI toolkits and components, as much as you can. That's the only way to discover what works well for your particular scope, and what doesn't. There is no uniformity at all between OS, screen readers and GUI toolkits, and probably no combination working everywhere in all cases.

Longer answer

This isn't a peasure to give this answer but in fact, if you want to make sure your app is 100% screen reader accessible, your only way is basicly to stop using GUI toolkits and exclusively use the native components offered by the OS for which accessibility is well documented; and therefore of course develop as many different apps as OS you intent to support. As soon as you are using a GUI toolkit, you are adding a layer, and may lose some accessibility (and often more than less) in the process.

The gap between the features offered by the native OS components and those proposed in the toolkit is often closed by emulation, and some of the emulations aren't made accessible, or simply can't be made accessible for various (more or less excusable) reasons. That's why some components are accessible while some others aren't; why a given component can be accessible under one OS but not at all under another; and why a component can be accessible in version N of the toolkit but not the same component in version N+1. In short, you have understood, accessibility is extremely fragile.

Sadly, GUI toolkits rarely well document accessibility of their components under the different OS they support. That's really a shame. It has to be addressed. Additionally, accessibility is often presented as being expert compicated features. It shouldn't be so. It should be easy for app developers to make accessible apps.

So, wwell, since there is often no documentation about accessibility, your only way is to try and test. That's a lot of work, and there is no alternative. Try and test. That's all.

Digging deeper

There's generally two foundamental ways to design a GUI toolkit, and depending on which has been chosen, this has a dramatic impact on natural accessibility, and what kind of accessibility the toolkit can hope to achieve.

• The first way is to start from a blank page as far as the OS permits, and from there, decide literally everything: what components to provide, and how they should look and behave. By doing so, you make sure that your app will look and behave exactly the same everywhere. An user might be surprised or confused the first time because look and behavior is often not 100% conform to OS conventions or user preferences, but in the long run, he/she will always feel at home with your app regardless of the OS used. However, more importantly, create everything from a blank page also means that everything must be defined from scratch for accessibility. It requires of course a lot of work, whether for the GUI implementers, or the app developer. Different toolkits place the responsibility cursor at different places. Some toolkits perform better and/or go further than others, but in general they are nowhere near what the native components of the OS can provide.
• The second way is to use as much as possible the components proposed by the OS, and emulate only missing features when they are really needed. This is excellent for accessibility, since almost all native OS components are naturally accessible or only require little effort. Users will have an app that conforms to the general look of their OS, and so won't be confused or surprised by the interface and its behavior. However, the app isn't going to look exactly the same in all computers. Sadly, for many designers and developers, this is a definitive stopper.

As the vaste majority of GUI toolkits I know of, QT is part of the first group, but isn't playing that bad in accessibility (at least under windows) if the app developer is also aware of accessibility. In the second group, you have WXWidgets for example.