Some accessibility issues

[nullatonce]

Windows 8.1 x64 Joplin 1.7.11

Bug:

• Menu bar is not readable by screen reader. Screen reader reads it as "menu" and "sub-menu" Expected:
• Screen reader reads menu bar elements like: File, Edit etc...

Bug/Improvement:

• When creating a new notebook you're just put to a input and not read what is expected (no label/title on input field i guess)
• Also landmarks for notebook's bar and note list would help. Expected:
• Items is readable by screen reader

Bug:

• When writing a note after each word screen reader starts reading everything from top of the note. Also same thing is happening when deleting words. Expected:
• Not loosing focus of textarea (not sure tho) after each word

Screen reading issues can be reproduced with nvda 2020.4

Thanks.

Some other, non-important findings:

• Behavior: Doesn't comply with high contrast black theme Menu bar (file,edit etc.) background keeps being white while text complies and turns white.

• Expected: Colors inherited from OS theme

• Reproduction:

• setting os theme as high contrast black from personalization menu

• Also would be nice if the working documents and list of notes would comply with system theme

[zersiax]

I gave this app a quick look a while ago and completely forgot to create an issue about this but yes, unfortunately the various interfaces of this app all suffer from accessibility issues, making it difficult, if not impossible, to use this app for quite a large amount of people, which is indeed a bug @laurent22. Can this be looked into? I'd be happy to advise, from a developer's point of view, if someone's willing to actually hear me out.

[laurent22]

That would be great if the app was more accessible but I'm not certain we have the resources to implement all this, as it's a project that would require multiple days of work. We try to follow good practices for the HTML structure and tags we use, and colours normally follow WCAG recommendations (we spent quite a bit of time on this when the new UI was implemented) but clearly there's more to do.

I mean if you can find someone willing to do the work, then why not. I suppose it would have to be split into several small pull requests so that each can be evaluated separately.

[zersiax]

I'd be happy to tackle some of them. I see that for example, the search button has no textual label, the "Tags" and "Notebooks" controls have no role ...that kind of thing is easy enough to fix. More tricky however is the editor component which at present appears to be completely inaccessible. What are you using, CodeMirror? If so, the current stable version of CM is completely inaccessible, something that has been fixed in v6, currently in beta. I'd argue that that is the very first thing that needs to be fixed; all the semantic HTML won't make a difference if a user can't see what he's typing :)

[laurent22]

Maybe some flags can be used to make CodeMirror more accessible? Otherwise indeed we'll have to wait for CM6 but it's been in development for a long time and we don't know when (or if) it will be released. The rich text editor uses TinyMCE. Is it any better in terms of accessibility?

[zersiax]

I'm afraid not ... CM just has a history of not being accessible and even large projects like FreeCodeCamp and Codecademy were rendered almost completely unusable by this same problem until they switched over to Monaco. I did try the rich text editor which does seem to work better, and external editing might help if I know what external editors are supported. I guess the other major thing would be keyboard-only or menu-based equivalents to dragging notes around from place to place. Can all those be done using the keyboard in the main desktop app? I like the fact you got right-click menus right, those are accessible in Joplin when they often aren't in other places, you did better than Spotify did for years :)

[nullatonce]

I want to say sorry for dumping everything in this issue, even the OS related things witch is not important at all, Indeed the main problem is unread html elements and (imo) the top menu bar (file, edit, etc.) this will make it usable.

I cloned the repo, poked around a bit, but yet have to locate those elements, even tho idk if i can be of any value due to apart from doing show/hide things in jqeury have no experience in JS/TS, not even talking about testing or compiling. Maybe will post snippets in here.

TinyMCE is accessible. The problem is that it looses focus after each word.

Not sure if this is of any value buy it seems adding title attributes works most of the time https://pastebin.com/UYiW6Yx7

[zersiax]

Ok ...so I am looking at the original bug report using Joplin v1.85 and here are my findings, using NVDA 2020.4:

• Menubar workst mostly as expected. When pressing the alt key, you are placed on a horizontal list of menus. When hitting down arrow on one of them, you are placed on a "menu collapsed submenu" which you can open with either another down arrow, or a right arrow. Either way, the menu options become visible at this point, complete with hotkeys and index indication. I would say while the extra step is somewhat non-standard, it is certainly usable.
• I can confirm that the edit fields , both for title as well as note contents, don't have a programmatically associated label, which means screenreader users don't know what they do. I haven't looked at the code to see how tricky these would be to fix. The search button, as mentioned above, doesn't have a label either, but the search input does, funnily enough.
• In the TinyMCE editor at least, I can't reproduce the loss of focus and the automatic reading of contents thus far in the editor. Essentially, it works fine for me for as far as I can determine.
• Tabbing around the interface at times seems to take me in strange paths through the application, but it, in combination with browse mode, seems to mostly get me places. I do agree that adding landmarks to various elements wouldn't be amiss though, this would speed up navigation significantly. Landmarks are semantic regions like header, footer, banner, search etc. but can also be manually defined.

On the whole, I need to play with this more to see what is genuinely not doable, those are probably the things that require the most attention.

[laurent22]

I can confirm that the edit fields , both for title as well as note contents, don't have a programmatically associated label, which means screenreader users don't know what they do.

They don't have a label because it's not needed. If we add something like a tooltip or title to the input field, wouldn't the screen reader pick that up instead?

The search button, as mentioned above, doesn't have a label either

Because it also doesn't need it, but maybe we can set some attribute instead that the screen reader would use?

Tabbing around the interface at times seems to take me in strange paths through the application, but it, in combination with browse mode, seems to mostly get me places. I do agree that adding landmarks to various elements wouldn't be amiss though, this would speed up navigation significantly. Landmarks are semantic regions like header, footer, banner, search etc. but can also be manually defined.

Under Go > Navigate, it's possible to jump to various key parts of the interface - is that what you mean? Otherwise the up and down keys are supported to move through the note list and sidebar.

[zersiax]

@laurent22 there are various ways to label things for screenreaders that don't have to show up visually. aria-label is probably the most simple solution for these:

<button aria-label="Search"><i class="SuperAwesomeSearchIcon"></i></button>
<input aria-label="title" ...></input>

Generally, you will want to avoid needless ARIA and use semantic HTML-based techniques instead, like making a label element with the for attribute which points to the to-be-labeled control, which you then hide with CSS, but in a pinch, adding aria-label should do in this case. As for the landmarks, yes, the focus hotkeys for the various controls fix this, I would say. So the only major issues currently are the markdown editor doesn't work, have to use TinyMCE, and the dragging of notes doesn't work, which for me actually is a dealbreaker. I need to be able to quickly take a note up and down hierarchy levels or move them between notebooks, Cherrytree style, and I don't really see an efficient way to do this without the mouse currently. If I'm missing something I'd love to hear it, of course :) And yes, I know the terminal UI probably does this better but unfortunately TUIs only work well with screenreaders on Unix-likes, not on Windows.

There is a VS Code plugin that talks to the Joplin Web Clipper API that offers a different UI for people who have trouble with the current one, unfortunately it doesn't solve my particular issue though :)

[laurent22]

I feel that different tasks should be created for each accessibility issue. As it is, this issue is too large so nobody will look into it, but if it's split into small items that can be independently worked on, it might be fixed over time. We could even flag the easiest ones as Good First Issue to get more people involved.

Also for example I've checked the menu items with a screen reader on macOS (using Voice Over) and it reads the item titles fine. So I don't know if it's fixed with a recent Electron release (tested with desktop 2.5) or the bug is specific to Windows. Another advantage of splitting into tasks is that we can discuss them separately and keep tack of what's working on what OS.

Would any of you, @zersiax or @nullatonce (or someone else) be interested in creating these tasks and keeping track of the progress?

[cary-rowen]

It is a good idea to split these tasks and implement them gradually.

[nullatonce]

@laurent22 hi, this thread slipped my mind, sorry for the delay. Yes, i can. In fact made a list before posting here. List has around 15 items in it (for accessibility and ui improvements). My question is should i open a new issue for each bullet point ? This can get spammy, and the bullet point is for a specific item should i merge them? if yes to wich point ? Currently i have "button after so and so link has no label" etc.

On the other note the app is now more usable, good job and thanks! On the other other note: maybe you would be interested in adding joplin to https://chocolatey.org/ (a package manager for windows)

[laurent22]

If it makes sense I think you can group certain issues. I don't know the details but let's say several buttons are missing a "title" attribute, then you can create a single issue for this, and list the instances you found that had a missing "title" attribute. If you have some doubts about some issues feel free to ask here. Also let us know the issues you have created so that we can label them.

Regarding the Chocolatey package, it's been available there for some time (although we don't manage it) https://community.chocolatey.org/packages/joplin

[nullatonce]

@laurent22 Nice! Probably miss Spelled when searched. Not sure how chocolatey works, but got newer version than from website :)

Opened issue about missing labels: https://github.com/laurent22/joplin/issues/5603

Will make more reports later.

[nullatonce]

Hi @laurent22 I'm confused. So after the "toggle editors" there is these two: Multiline edit field And a clickable area (before frame of what i assume is a preview)

What are those ? Wrote issue treating first one as a input for the note than got confused for it being a note name (clearly it isn't). SOS.

[cary-rowen]

Is there any update on this issue?

[cary-rowen]

@laurent22

[cary-rowen]

Hi @akash07k

Do you have any new ideas for this Issue? Is it possible for you to contribute to this?

Thanks

[akash07k]

@cary-rowen Yes, Probably I'll contribute some fixes to the codebase. However, now I'm planning to develop my own Open source note taking app with the accessibility ground up. The fact Joplin is based on Electron clients makes me lose interest in it.

Hi @akash07k

Do you have any new ideas for this Issue? Is it possible for you to contribute to this?

Thanks

[cary-rowen]

@akash07k wish you success, Joplin's long-standing accessibility deficiencies made me give up on using it.

[akash07k]

Thanks. I'll soon publish the project on GitHub

@akash07k wish you success, Joplin's long-standing accessibility deficiencies made me give up on using it.

[zersiax]

@akash07k did you eer get anywhere with this?

@laurent22 Honestly, I would be happy to work on the accessibility of Joplin. However, we are first going to need to find a solution for the CodeMirror editor issue. Like I said in my original comment, until that gets swapped out, anything else doesn't matter, and this has been a problem for years now. I looked into this issue again today and earlier you said the rich editor might be better. I can't currently find the rich editor, has it been removed?

[laurent22]

Unfortunately it's unlikely we'll switch to CodeMirror 6 any time soon since it would be a major change. It's really just unusable with accessibility tools?

As for the rich text editor it's still there if you click on the button in the top right corner

[zersiax]

Yes, it is completely unusable. You cannot see what you type, you cannot read the contents in the editor and you cannot easily make edits because of these reasons within the editor. This editor alone has been the reason a number of big projects (Codecademy, freecodecamp, codePen) were, or in Codepen's case still are, completely unusable without time-consuming an awkward workarounds. Most of these projects have switched to Monaco rather than wait for CM6, but even CM6 would be better than this.

[personalizedrefrigerator]

Another option would be to enable the plain text editor on desktop for screen reader users (a screen-reader-accessible/tab-key-reachable only button could enable this editor).

[zersiax]

That could work provided there's feature perity between it and the markdown editor. If not, we can just use the rich editor. The rich editor works ok, just has a lot of limitations it looks like.

[cary-rowen]

Microsoft's Monaco editor has good accessibility.

[personalizedrefrigerator]

With CodeMirror 5, it seems that enabling spellcheck in Joplin's settings fixes some accessibility issues (testing with VoiceOver on MacOS).

Internally, enabling spellcheck switches from the textarea to the contenteditable input mode. The latter seems to better support screen readers.

I've also created a pull request that migrates the desktop editor to CodeMirror 6. It might take a while for this to be available, however.