Native Dendron Panel

[kpathakota]

Context

Dendron should have it's own native panel inside VSCode
Foundational for future UI features + Authentication.

Proposal

• Support subtree hoisting Ways To View Subtrees -- Hoisting #664
• Authentication support

[zersiax]

Just stumbled across this tool and loving it :)
One of the reasons I love this so much is that this, other than a HUGE lot of other notetaking tools, actually works really well for screenreader users, of which I am one.
I'd love for this project to improve, of course, but please, try not to break accessibility when going native :) I'd be happy to test things as they become available and lend my expertise as web accessibility expert to prevent this from happening if required.

[kpathakota]

@zersiax - will take you up on this :) By going native, we really only mean adding another panel within vscode. It seems like vscode integrates pretty well with the screen reader by default but it really would be helpful for you to take a look and file issues as you find them for accessibility :)

Our goals align quite well because we want Dendron to be used as much as possible purely with the keyboard/shortcuts.

[zersiax]

It does :) Particularly with trickier UI patterns like treeviews, autocompleting lists etc., the keyboard aspect is one half of the puzzle. The other half is making sure the screenreader understands what to say when, e.g., an autocomplete form field won't do an SR user much good if the suggestions aren't announced, even if it's fully keyboard-accessible :)
Feel free to poke me when i need to take a look :)

[kevinslin]

Hey @zersiax

We have our first native web view component live. Instructions to setup are here. Would love to get your thoughts on it and how we can improve, accessibility wise. This view is build using Antd Design

[zersiax]

There ...really is no gentle way to say this :) This component would, perhaps, have been ok-ish for a one-off thing on some obscure website I have to visit on a relatively normal thursday afternoon. For something like Dendron, however, it's currently practically unusable, and that mostly has to do with the way this component has been implemented.
An example of a working, for screenreaders, treeview can be found here:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/treeview/treeview-2/treeview-2a.html
For React, the first example on this page works rather well. I looked at two others , both of which were iffy, though:
https://morioh.com/p/98b506190f6d
These treeviews work, because they have the correct ARIA properties defined on the relevant DOM elements. That Ante hasn't done this saddens me given they are apparently one of the more common react UI toolkits.

What works?

Currently, very little. I can see the treenodes, but only in what is known as a screen reader's browse mode, which is used to read longform web content, not to use web applications.
If I were to click the image with the alt text of "caret-down", I can expand things. The "+" icon is visible in front of stubs.

what does not work?

Screenreaders don't know this is a treeview. That is the main issue. They don't know it's a treeview because rather than the correct HTML elements, the developers seem to have gone with augmenting simple div elements with all sorts of React goodness to make it look, walk and quack like a treeview for everybody BUT technology that actually depends on semantic markup to be done according to spec. This means that:

• The treeview is not marked up as a treeview, won't be reported as such, won't let SR users navigate to it or away from it in any meaningful productive manner.
• • The items in the treeview are not marked as treeviewItems, in fact, they don't have any role (button, link, checkbox etc) at all. This is a big accessibility no-no and would make this component fail any audit for just this.
• I don't know if keyboarding through the treeview works. Normally, right arrow expands, up and down move between siblings, left arrow collapses etc.; you can try this out in the example I linked above. If any of this works, screenreaders don't give feedback that it does.
• There is no way for a screenreader to determine what element is a child of what parent, how many levels deep that child is and if an element is collapsed or expanded.

SO ...yeah ... it's a treeview Jim, but not as we need it I'm afraid. This is pretty much the scenario I was envisioning when I first reached out and I am extremely happy this is a toggle for now ;)

How do we fix?

That's an interesting one, I don't know how much of the UI is custom. If you wrote this mostly from scratch you should know enough now on how to fix. If you didn't, then this isn't necessarily something Dendron needs to fix unless you want to contribute the fixes upstream. This really is an Ante issue in that case, though.
If it's pretty much a drop-in, consider using another drop-in :) The second link up top is react-compatible, just not sure how old it is.
If you slaved away at this ...welp ...sorry I don't have better news for now :)

[zersiax]

Heads up, I just went to go look at what the example treeview looks like over at their website and see the exact same behavior, so this is definitely an Ant issue. I opened an issue on their repo for this here:
ant-design/ant-design#31012

[kevinslin]

Hey, thanks for taking a look and apologies for the delayed response.

Antd has a lot of components but one thing they've known to lack is accessibility. We'll look at other tree views. We're also coming out with a calendar widget this week, would be great to get your feedback on that as well, accessibility wise.

The web ui is currently opt in and we'll keep the old views around for as long as necessary until we have an accessible web ui equivalent.

this might take some time since we currently have a bunch of projects that we're juggling so please bear with us in the meantime.

if you have any recommendations for resources and qa tools in this area, we'll make a best effort to take this into account

[zersiax]

All good :) I essentially got told that my issue "was a good feature idea, and they were awaiting my pull request". Needless to say ...i gave that one up for now.
As for recommendations, I did a bit of digging. Your best bet is probably this one:
https://next.material-ui.com/components/tree-view/

An alternative is the second link in my feedback comment, or this one, though note that that one has not been updated in two years and may therefore not be compatible with latest react:
https://github.com/lissitz/react-accessible-treeview/

Thanks a bunch for keeping this topic in mind,and I'd be happy to look at the calendar, just let me know what to look at when :)

[aleksey-rowan]

Does VSCode itself use a tree component from some library or did they build it from scratch? If it's external, maybe you can just use that.

[kevinslin]

I think they built it from scratch. But there are a bunch of options in terms of accessible tree view components. For now we will make sure that the old tree view doesn't go away until we implement an accessible solution

…

On Sat, Jun 19, 2021 at 6:32 PM Aleksey Rowan ***@***.***> wrote: Does VSCode itself use a tree component from some library or did they build it from scratch? If it's external, maybe you can just use that. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADD52OBWKM2AS44ZMATOP3TTVAKRANCNFSM446YKVSA> .

[aleksey-rowan]

I have a few requests for the new tree view (is this a good place to post them?):

• make it feel more like the native VSCode tree (fonts, sizes, margins, etc.),
• an option to disable tree animation on expand/collapse (the transition delay is annoying, to me at least),
• an option to toggle wrapping of note titles (and truncate with ... as it's done in the v1 tree),
• an option to display file names (as in v1 tree) instead of note titles in the tree,
• and Better icon placement in the Tree View #767

Although, it probably makes no sense to do any of the above if you are going to replace the Ant tree with something else in the near future.