Accessibility fixes for JAWS screenreader

[vwbij]

I am working on some accessibility issues with the JAWS screen reader. JAWS does not see the text in the edit lines. I analyzed it and found the following reasons:

• The [div] of each line need to have the role "textbox" and an aria_label (with a speaking name)
• The aria role of the body is "application", that stops the screen reader analysing the text. And - by the way - it is not allowed to set a ARIA role at all in a HTML body.

I've looked into the scripts and found a first way to fix it. Now I have some questions to You, the involved developers:

• How do I activate some debug output? I found "Console.log" was throwing a exception.
• What I have to do to integrate the modified code into the EtherPad project after testing it?
• I modify< the node after the node was created in "CreateDomLine". I have seen that a lot of events for plugins are executed in this function. Is it a problem to modify the node by setting a ARIA role and label without any chance for the plugins to have an influence on this? Is it possible that a plugin has set this data, and it is needed to take care about it?

This are the questions I have until now. I am happy to help working on this nice project!

[webzwo0i]

Thanks, for the questions!

There was some amount of work done in 2015 #2566 (and some discussion in #1803 ) and there is a more general wiki page at https://github.com/ether/etherpad-lite/wiki/Accessibility but after that I think we didn't had much input, so it's very welcomed.

During the change in 2015 aria role "application" was introduced. I can't find a rationale behind the change, though. It seems to work with https://help.gnome.org/users/orca/stable/ , ie orca does read the single divs. But let's remove this and see if it helps.

The aria-label for all divs is more complicated. We can identify list items and headings in case ep_headings2 is used. Would that be enough, so that we have labels for "list-item", "heading of level X" and "text line"? There are more plugins, but they often don't extend to the whole line, so we get mixed content.

Regarding your questions:
console.log is the most valuable source of information for browser-side code. When you run your own Etherpad instance, you can increase the loglevel to DEBUG (it's a option in settings.json), but this is used for the backend part.

After you have your changes ready, you would need to make a pull request. Take a look at our contributing guidelines

I think you shouldn't need to pay special care to plugins. Theoretically say can mess with those attributes, but let's assume they don't. I feel like it's better to add them directly in domline.js before returning the domline.

[vwbij]

Thank You for the fast answers!

Your Idea to have different labels for headings, list items and text lines is great. I was thinking about including the line number, but after tracing the code I found no easy way to do so. Every press of return changes all following line numbers. So I skipped this idea.
Is it possible to use localisation for the ARIA labels, and how is this done? So it would be possible to use in english "Line" and in german "Zeile" for the labels.
Yes, "console.log" works great, like I found in google, after I was writing it like "Window.console.log". Before I was banging my head against the wall wondering why the copied code from the web did not work at all :-). That's the way to learn a new language :-).
You're right, domline.js is the best place to do the work, after I've cancelled the idea with the line numbering.