Desktop: Accessibility issue with desktop client

[Adriorjalesvidal]

Hi
There is a issue with the Nextcloud Windows client related to accessibility.
If you use a screen reader software to review the screen, you are not able to interact with the main Nextcloud dialog.
It is a very important issue to visually impaired people like me.
The buttons are focusable but not poperly labelled, and if you use the mouse to review the dialog the screen reader reads nothing.

Here is the info:

OS: W10
Screen reader: Non Visual Desktop Access (NVDA)

Steps to reproduce:

1. Install NVDA, it's free and open source
2. Install Nextcloud Windows client
3. Connect to a server. (On this step, accessibility difficulties are present but not critical)
4. Once the program is running, click on the background tasks windows icon from the task bar
5. Click in Nextcloud Icon. The main Nextcloud client dialog appears
6. Try to interact with the screen using NVDA. Nothing will happen, nothing is read, including tabs and mouse focusing.

If you need help with the Windows client development, please tell me how can I do to help you with this application, or how can I join the development team.
Thanks

[kesselb]

cc @nextcloud/accessibility @jancborchardt

[tyrylu]

Agreed. No idea why the designers of the main window decided to use icon only header buttons and because i have no experience with QML, i have honestly no idea whether it it is possible to set accessible names for these (e. g. an equivalent of QWidget::setAccessibleName). There are other issues, for example the indication of selected folders is completely broken in the selective sync dialog and probably others. Honestly, writing a fully accessible QT app is hard, but the settings dialog, for example, is quite good on this front.

[Adriorjalesvidal]

If the main dialog window is developed using QT framework, it will be difficult to solve accessibility issues. As I've learned using Linux QT based graphical desktops, screen reader Orca cries when it needs to interact with QT. I think that NVDA supports QT, because I think Virtualbox hypervisor is developed using this languaje, and since it is not the best accessible interface, it is usable. In the other hand, if the settings pages are "accessible" or usable, I don't understand why main dialog is not.

[jancborchardt]

@Adriorjalesvidal @tyrylu I’m very sorry about this, it’s a really bad oversight and completely my fault.
As a workaround, a right-click on the tray icon reveals a normal menu with "Open main dialog", "Settings" and "Exit Nextcloud". Picking "Settings" will go to the old main dialog. I hope that already helps.

Now for the fixing: We also talked about this the other week among the desktop app developers so we are aware of this.
@er-vin @DominiqueFuchs @misch7 @camilasan can one of you check this out? I’m happy to also sit together on this, I’ll just be on vacation for 2 weeks. We should make sure the main dialog works properly in an accessible way.

[camilasan]

If you need help with the Windows client development, please tell me how can I do to help you with this application, or how can I join the development team.

We have some information in the README and in the wiki on how to contribute:
https://github.com/nextcloud/desktop/wiki

[tyrylu]

Thanks for these, but someone who has already the entire dev environment setup could just for starters add Accessible.Name for the HeaderButtons.

[jancborchardt]

Thanks for these, but someone who has already the entire dev environment setup could just for starters add Accessible.Name for the HeaderButtons.

Yep, thanks! This is also what we talked about adding. @DominiqueFuchs is working on a pull request for this.

[jancborchardt]

@Adriorjalesvidal @tyrylu now Dominique opened a pull request to fix this, would be great if you can check it out:
https://github.com/nextcloud/desktop/pull/2317

My biggest question in there often is if we even need the "Accessible.description" at all if the "Accessible.name" is already very well worded. Thanks for your help!

[Adriorjalesvidal]

Hi @jancborchardt, thanks for your help!
I think there is not need to overload items with accessibility descriptions. A simple item needs a simple name, and it's enough to understand what it will do if you activate it. Only items that are not self explanatory will need a long description.
In the list of recent changes that appears in the center of the dialog, the accessible name would be better if it was the type of activity reported, and the name of the synk object affected, something like "Downloaded folder Pictures button". Open function will be understood by user. I comment this because I am not sure if one of your comments on the code is related to this topic
Thanks for your collaboration, it's really appreciated.

[jancborchardt]

I think there is not need to overload items with accessibility descriptions. A simple item needs a simple name, and it's enough to understand what it will do if you activate it. Only items that are not self explanatory will need a long description.

Thanks! That’s what I know from the web as well, so I guess it’s quite similar like in HTML accessibility?

in the list of recent changes that appears in the center of the dialog, the accessible name would be better if it was the type of activity reported, and the name of the synk object affected

So right now e.g. an activity says: "You changed file.pdf". I assume that text is read out?
And then Accessible.name could be "Open file.pdf locally`?
Or will Accessible.name overwrite whichever text is read out, and we will have to add a description instead that clicking on the entry will open it locally?

[Adriorjalesvidal]

Thanks! That’s what I know from the web as well, so I guess it’s quite similar like in HTML accessibility?

Yes, I think it's the best workaround.

So right now e.g. an activity says: "You changed file.pdf". I assume that text is read out?
And then Accessible.name could be "Open file.pdf locally`?
Or will Accessible.name overwrite whichever text is read out, and we will have to add a description instead that clicking on the entry will open it locally?

In your example, text read by screen reader will be only the Open action, and people will don't know which file is associated with this action.
In this case, there is a problem. The item we are talking about, is a clicable item, that simply opens the folder/file related to it's content, but the important thing is not the action that the click will produce, the important information that a screen reader must read in these situations is only the text that is displayed, because it will not be read if you don't include it in the name of the item. And also, if you want, you can add a long description attribute and on there, write the action that will be happen if you activate the item. I write an example:
We have the following clickable item:
You've updated file cv.pdf.
Short description could be:
You've updated file cv.pdf.
Long description could be:
Activate to open

When I talk about short description, I am talking about accessible name attribute.

I hope I have been helpful

[tyrylu]

E. g. Accessible.name overrides whatever QT would provide for a widget.

[jancborchardt]

Ah perfect, thanks @Adriorjalesvidal @tyrylu! (Sorry was on vacation, hence my late reply.)

So for the new structure as discussed in https://github.com/nextcloud/desktop/issues/2325 it would be:

• Text is only the filename like "Document.pdf" and the subline "Edited 4 hours ago · Documents / Project / Customer A"
• Accessible.name of the entry would be "Open Document.pdf"
• Share icon Accessible.name would be "Share Document.pdf"

That would be minimally invasive and be very explanatory, right?

[tyrylu]

That sounds good.

[er-vin]

I'd welcome some testing of tomorrow's daily. We merged the PR introducing more of the accessibility support so feedback would be welcome to know how far off we are.

[er-vin]

Any news there? I'd be willing to just close it because at that point I think it's addressing the concerns expressed earlier.