Accessibility issue with onscreen keyboard use


I’ve been using the free RS DesignSpark software for a long time but would seriously like to use KiCad, however being paralysed from the neck down and using a headmouse and an onscreen keyboard (WiVik) on Windows 7, I’m finding the software essentially unusable and very inaccessible.

For example, in the Page Layout Editor it is impossible to edit any text. If I select some text to edit then try to use my onscreen keyboard (other onscreen keyboards suffer the same problem) it looses focus and becomes impossible to edit. This is the only program I’ve experienced in many years that does this. The effectively renders the program useless to me.

KiCad’s heavy use of keystrokes is also a pain as I often rely on toolbar buttons for simple tasks such as cut and paste etc., which seem conspicuous by their absence, unless of course I can’t find where they are, which is also highly plausible :slight_smile:

The absolute killer though is the system’s apparent inability to place nicely with an onscreen keyboard as far as I can determine, unless I’m missing something and somebody could point me in the right direction?

Any help would be greatly appreciated.

Thanks very much in anticipation.



1 Like

I’m just testing this on Kubuntu with “onboard”. I can edit text with that onscreen keyboard app. The problem is Windows only and I can confirm it. The panel where the text is to be edited (Properties of the selected item) seems to be overall crappy, the layout doesn’t work well on Windows or Linux, in the stable version or 5.99. I’ll report this as a bug.


1 Like

KiCad’s toolbars are static which is a well known limitation and the developers are willing to change it, but I don’t know if it will happen for v6. We hope we will be able to edit the toolbars to our liking.

Until then, the actions are of course in the main menu under Edit and also in the context menu. I suppose you can use the context menu (RMB menu)?

To be honest KiCad isn’t designed for on-screen keyboard. It relies heavily on two hands, one on the keyboard and one on the mouse. But maybe the developers are willing to consider something if you file an issue and tell about your experiences.

I also did a little test on my Linux Mint 19.3 box, also with the “onboard” onscreen keyboard, and it seems to work as expected:

So it may well be a windows specific bug, but I do not use windows.

@eelik You entered Linux version info on gitlab for a (probably) windows related bug. This seems somewhere between useless and misleading.

Can you add the complete version info to the gitlab issue, or at least post it here? You can (hopefully) copy that info with: KiCad / Help / About / Copy Version Info and then paste it here on the forum. (Eelik should then be able to replace his version info, with your version info on gitlab.)

1 Like

@paulvdh Thanks, my version info is:

Application: KiCad
Version: (5.1.6)-1, release build
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:

Thanks @eelik how do I go about filing an issue with the developers being a bit of a newbie here?

You need an account in KiCad application issues are in, there’s the New Issue button there.

Each issue should have one specific problem only. Apart from the Page Layout Editor issue, you have at least two: toolbar buttons (which will probably be fixed by having customizable toolbars and therefore isn’t worth reporting because it’s already known) and the generic dependency on physical mouse+keyboard. Report that latter one, but I wouldn’t expect any quick solution or fix. It’s still good that the developers know the situation.

@eelik Cool, thanks very much, I’ll do that and thanks ever so much for your help too.

To be honest i fear a fully fledge CAD tool will not be able to fully get rid of mouse+keyboard dependency. At least not while allowing the same efficiency of use as with keyboard + mouse. However a core feature set could be defined that is available to anyone no matter their limitations.

The speed of hotkeys can of course never be achieved without physical keyboard. Modifier keys (holding down Shift, Alt, Ctrl etc. and using mouse are a different matter because as far as I understand it’s impossible to press an OSK key without moving the mouse back and forth. Some actions in KiCad rely on having the mouse first in the correct place, then pressing modifier keys. I wonder if there’s functionality which can’t be reached without them.

Perhaps a voice command option would be a more efficient longer term solution

Thanks all for the comments.

A full blown CAD will always be more efficient with hotkeys undoubtedly, however that certainly doesn’t preclude the possibility of alternatives for easing accessibility for pretty much every operation.

As I mentioned in my preface, I’ve been using the free offering of DesignSpark by RS for a number of years, so it can be done, I really wanted to look at moving forward with a better system though. Some things will always be slower for me, I understand that, it’s just part of life I’ve got used to.

A double click in KiCad to select/highlight a component to work on would be invaluable for example.

What do you mean by “component”? ATM the symbols and other items in eeschema aren’t manipulated like in other programs. In the development version 5.99 (“nightly builds”) and in the future 6.0 eeschema works differently. Because you’re not probably doing a complete project with KiCad right now (or are you?), you could very well test the nightly builds. All the feature development happens there anyways, and you could give valuable suggestions.

1 Like

A quick caution about using the bleeding edge nightlies (currently marked as v5.99). It is known that backwards compatibility (a project saved with the current nightly) is highly unlikely to be able to be opened in the current published stable (v5.1.6). But there is also the possibility that a project saved in today’s nightly won’t be openable in tomorrows nightly. It is a development version where different features are being tried out, and implementations may change.

I’m not saying to not try the nightly, but don’t do any real work in it as your work may become stuck to the last nightly version that it was saved in. You do have a unique perspective on implementation and how to use your accessibility interface. If I were designing UIs, even if I tried to use your interface tools I may not use them “correctly” out of ignorance because of my non-handicapped privilege. But, you may not have the time or energy to devote to this so please don’t feel like I’m trying to unduly pressure you into being the KiCAD accessibility interface expert.:wink:

1 Like

@eelik No, I’m not doing anything serious with KiCad at the moment, I just wanted to start learning it before I started a serious project, so happy to try the nightly builds and offer any suggestions I can.

@SembazuruCDE I haven’t got any projects at the moment and don’t find V5 very conducive to my circumstances, so I’m happy to try the nightly builds to see what they have to offer. My circumstances are unique to my disability, and every disability is different so it’s very difficult to be all things to all men, but if I can help in my own way then I’m more than happy to.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.