qubes and screenreader users

[Elias Ståhlberg]

hi
I am a completely blind user and my intention would be to use qubesos.
orca screen reader can be installed in app-vm so it works in them but
what about the dom0 management layer, adding, deleting virtual machines,
changing settings etc. Of course, dom0 itself does not install anything,
it would increase the attack surface, but I understood that qubes is
separating the gui into its own virtual machine, thus the management gui
would run in its own virtual machine where I could install screen reader
and that virtual machine would apparently be connected to dom0, so the
virtual machine management would be successful through that. There was
some discussion about this on the mailing list earlier, has this already
been implemented or could this already be tested

https://forum.qubes-os.org/t/qubes-users-screenreader-accessibility/1895

Elias

[unman]

Hi Elias

Welcome to Qubes.
I'm sorry for the delay in replying - I've been away.

I know of a number of blind and partially sighted Qubes users, so you
are not alone. Few of them frequent the Forum - too much noise. I
usually recommend use of KDE because it has better accessibility and
can be configured in ways that better support Qubes use, but you may
have your own preference.

Some general remarks first.

Many of the widgets are not easily (at all) usable with orca, so users
tend to fall back to the command line. They often have many helpers and
short cuts to generate limited output, useful if you have many qubes
and templates.

Users often allocate Persons to domains - this is not ideal
because that is under the control of the qube, so I supplement it with a
simple script that reads the name of the qube under the active window,
and the name of the current Activity, linked to a shortcut. You can feed
relevant detail to espeak-ng. Users sometimes add the color of the
window: all this is generated by dom0 and not the qube.

The other thing I would recommend is extensive use of qubes-rpc
policy, to help avoid any leakage of data between security domains, and
to simplify transactions between qubes. In many cases you will find that
transactions like copy/paste, move, can be limited to one or two target
qubes, which helps to avoid mistaken transfers. This is just one of the
places where thinking carefully about how you will organise your qubes
before rushing in will pay off.

Now to your question. I dont have a great issue with installing orca in
to dom0, and while the GUI domain is there, it's useful, but not
essential. That is, I could get by with espeak-ng for most purposes.

It is possible to set up a management qube, from which you can control
your Qubes and use the command line tools. I run this on some systems,
usually accessible remotely, and have orca installed there. Users who do
this usually give the management qube full access to the system,
although it would be possible to restrict that qube to some essential
activities, once the base system is set up. Salting qubes from outwith
dom0 is possible but requires some particular changes to sls files and
use of qubesctl: that's quite niche.

The core document for starting with a management qube is at
https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/ - this should
give you some grounding in the approach, and how it can be implemented.
It's a good read. If you need help with the set up or specifics call out
and I'll see what I can do to help.

unman

--
I never presume to speak for the Qubes team.
When I comment in the mailing lists I speak for myself.