[REQUEST] Accessibility Improvements

[zersiax]

Currently, the interface COULD be very accessible, but isn't. A lot of elements don't have semantic roles, the interface is almost entirely mouse-centric and the experience for, say, screen reader users is just far from optimal.
Adding the required semantics to the interface can already improve the experience quite a bit. Giving the various icon-only buttons a textual programmatic label (i.e. through aria-label) would already help a lot as well.
It appears that, through some Atlassian-originating code, drag-and-drop can be performed by hitting space on an element, moving the keyboard somewhere else and hitting space again to drop. However, currently, screenreaders have no idea where they are in the interface because the tree isn't an actual semantic tree, rendering this somewhat useless :) Any mouse-only action should be callable from the keyboard as well though.

Additional context
Add any other context or screenshots about the feature request here.
I'd be happy to answer questions about this if and when people are interested; i am a screenreader-using developer myself which puts me in a unique position to do so.

[lukasbach]

Hi @zersiax!

Thank you very much for your feedback. Yes, I'm unhappy to agree that Yana really isn't accessible in most ways. This is a topic that I'd definitely like to address at some point, unfortunately I have been occupied with my master's thesis for the last months, and I think that, improving the accessibility of Yana includes some bigger efforts. This is also somewhat related to #13, as I want to generally improve the usability of Yana with keyboard-only.

The tree that lists notes in the workspace uses an atlassian framework for rendering trees, I thought that it would render semantically correct. However, I thought about replacing the tree with a custom implementation anyways that supports selecting and moving multiple items at once. By the way, moving items (which is what dragging-and-dropping here does) can also be done by right-clicking on an item and clicking "Move to...", although I'm not sure how easy that is to reach via screenreaders. Can screenreaders invoke context menu actions (and does the screenreader properly inform on sections that can invoke a context menu?), or is it generally preferred to have alternative ways of accessing those actions without having to invoke a context menu?

I'm happy that you are interested to use Yana, and sorry that it currently is hard to use with accessibility tooling. I'd like to let you know once I managed to improve the accessibility of Yana to get some further feedback then if that's okay with you.

[zersiax]

Hi :) Thanks for getting back to me :)

The Atlassian influences are definitely noticeable, yep, and unfortunately mostly in a bad way. There's certainly a better way to code up a treeview for accessibility, mostly by using already existing semantic solutions:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/treeview/treeview-2/treeview-2a.html

This would be the HTML skeleton after which JS can be used to enrich it :)
As for context menus and screenreaders, it sort of depends. If the element responds to the applications key, or shift+f10, then that is perfectly doable with a screen reader. In a punch, a screenreader can move the mouse to where it thinks the item is on screen and simulate a right-click, but that is not as good UX-wise. As for the menu itself, there are patterns for that as well. Projects like VS Code do this right, so that might be worth a look, but essentially you'd want to either hook into an existing mechanism for this that Electron provides if such a thing exists, or programmatically move keyboard focus to the first menu item and allow for up and down arrow navigation the way you can in traditional context menus. That will help non-screenreader users who just like working from the keyboard, as well :)

I absolutely get a master thesis would take residence so please just poke me if you have anything to ask or anything for me to look at. I'd take a crack at it myself but I'm relatively new to Electron development so I'm not sure how much use I would be :)