Issue #320: Accessibility problems with kallithea and screen readers (conservancy/kallithea)

[Michael Taboada]

New issue 320: Accessibility problems with kallithea and screen readers
https://bitbucket.org/conservancy/kallithea/issues/320/accessibility-problems-with-kallithea-and

Michael Taboada:

Hi,
First off, I am blind, so use a screen reader to access my computer. On linux I use orca, on windows I use NVDA or Jaws for Windows (depending on the thing I'm doing), and on mac I use the built in voice over.
The problem is, kallithea has some (relatively major) accessibility problems. I'm going to provide some general problems, and then give some examples of specifics:

Generally, many items are clickable elements, instead of links, and screen readers do not do well with such elements. There are also links that are clickable links, meaning you can press enter on them, and they will load a page, but clicking them either opens a menu under them, or loads a different page. Also, there are some sections where clickables (which should turn into links as with the others) flash on the screen and disappear. This is most prominent with user/group selection fields, where you type a search (a whole name, part of a name, etc) and then click the item you want. The problem here is, I would guess, that upon exiting the field, a search list pops up, but, the screen reader interacts in such a way that the javascript thinks you have moved your mouse away from the list or something so almost immediately closes it. Also, some sections are not labelled properly. This is mostly seen, once again, in the user/group selection UI, though this time in the permission selection (none, read, etc). I also noticed that even well labelled radio buttons (such as the apply to which children selection on repository group permission pages) don't seem to think you've selected them, even when I use the space bar to, so when clicking save it reverts.

Now, some suggestions how to get around these issues:

For clickables, basically the only way to fix them is to make them into a "true" clickable element (meaning an element that is natively accessible with the keyboard without screen reader hacks), such as a button or link. The alternative is to write custom javascript to detect keys being pressed, but let's just not go there. For the links that do different things when clicked, I would say they need to either be re-written to accept a keypress (such as enter or space bar), but only expand, not load the new page. That last part is more of a usability issue, but nevertheless. This would kill two birds with one stone, one being making it much easier for screen reader users to access the menu, another being that instead of having to click (or press a key), load another page, then re-navigate to the same spot where you were, you can just press a key and go. The radio buttons need to either have a label element, or be put in a "true" html table, instead of just text being aligned with css or similar. This would make most screen readers read the proper label, rather than just "radio button" or "<name> radio button". Preferably actually both of these would be done, as tables provide much more structure for the thing that is, essentially, a table for screen readers, and the labels would guarantee that even slightly less well-behaved screen readers would work well with them. As for the flash menu problem, the only real thing I can say there is that the menu can't disappear when it thinks the mouse has been moved off of it, or otherwise it just needs to realize when a screen reader is doing the "moving" (much harder than is necessary imo).

Lastly, for better usability for screen reader users, headings should be added in key places. One big one that is only done on a few places (like a specific repositories page) is to put a heading at the top of the content (above the links for the repository, for example). This is already done in repositories, but almost nowhere else. Other places could include above the settings fields on a setting page, at critical points in a page, etc. It just makes screen reader users' lives much easier as they can press one or two keys to move to the right place, as opposed to having to down arrow 10,20,30+ times.

I will add to this issue if I find anything else, but I think that list gives a pretty good summary of what I found wrong with the accessibility, and more than enough to work on :-).

Thanks!

-Michael.