Improve accessibility for blind people and other users of screen readers

[lizzard]

Might there be some ways to usefully improve Etherpad Lite's accessibility? I know that people who browse with a screen reader can't use it. Etherpad is so useful that I hate to turn away from it as a collaboration tool. Is this something you have discussed already in issues or in a forum? I looked, but didn't find anything. If I can help gather suggestions I'm happy to do that.

[JohnMcLear]

you can do text to speech and speech to pad
If you extend ep_themes you could create a high visibility theme.

[JohnMcLear]

@lizzard did you get chance to try out ep_themes?

[lizzard]

I will not have a chance for another week or so, but thank you for the idea John! I'm not sure what the exact issues are but maybe can work with others to collect info on what makes it so unworkable at the moment (compared to other collaborative editors)

[dbolter]

Hi John, could you elaborate on what you mean by "you can do text to speech"? Of course screen readers already employ TTS as part of their solution - is this what you mean - or do you mean that there is some TTS option built into etherpad-lite (which would make it a "self-voicing" app in accessibility terms)?

I may be able to help with this issue but I want to make sure I fully understand the current status of things.

[JohnMcLear]

Ah if your screen reader already does it then just ignore me :)

[dbolter]

:)

So I think Lizzard filed this issue because existing screen readers can't currently work well with etherpad. The problem is that browsers are exposing the DOM structure and mutations but they are atypical for text areas/editors so the screen reader can't correctly make sense of them. The work to fix this would likely involve similar work to what they did in the orion editor (I have contacts)...

[marcelklehr]

What changes would be necessary to allow people behind screen readers to
use etherpad?

(Or rather: What are screen readers capable of in terms of web technology?)

[lizzard]

I don't know the details and am not a screen reader user. But have had reports from friends who are blind and use screen readers that Etherpad is not accessible for them. For me this is a problem because it's a collaboration tool that we use often at work at Mozilla! I love Etherpad, and was using it for bug triage meetings --- but unless it's useable for screen readers I don't want to leave out any of my community. So, I've been using wiki pages or Google Docs instead. I would be happy to work with dbolter to try to find testers or developers at least to report or explain what doesn't work as well as to outline what might be done to fix the DOM structure for screen reader navigation.

[MarcoZehe]

Hi all! To re-kindle this: The markup inserted into the contentEditable that is the text area must be compliant. So if somebody formats something as an ordered list, an ol and li elements must be inserted. Same for headings: A heading of a certain type is h1 through h6. Paragraphs are p elements etc.
When I tried EtherPad last, I got a lot of differently styled divs, or at least I assume they're differently styled, but no semantic markup that I could make sense of. So I didn't know what were headings, what were list items etc. Also, the tool bars would need keyboard accessibility and markup work so they register as toolbar containers, buttons etc. and react to key presses in the same way they react to mouse clicks.
I can help test and comment on patches. My blog at http://www.marcozehe.de has a lot of examples and articles on the WAI-ARIA and HTML5 accessibility topics, too (in English).

[sathomas]

As an FYI, here's some info on how Google Docs handles accessibility

[MrSchism]

Preface: I am sighted and have not used a screen reader.

My interest is in how it scales. It's chaotic visually, but a reader sounds even more so. It seems like it would be fine being between two people, but exponentially crazier after that, largely due to the limits of the reader.

[JohnMcLear]

Help us help you: https://www.bountysource.com/issues/1371778-improve-accessibility-for-blind-people-and-other-users-of-screen-readers

[JohnMcLear]

Hey guys, I have been tasked with working on this so if anyone can jump in and help please say! :)

[sathomas]

Hi John. I'm definitely interested in working on this. I'm swamped at work for the next week or so, but might have some time to help after that. I have no knowledge of the Etherpad code base, but, as a user, I do have some ideas on how to improve its accessibility.

One suggestion I'd make is to first worry about the single user case (saving the live collaboration case for the second phase.) Even though one of Etherpad's major features is collaboration, I suspect there are plenty of folks that use it, at least some of the time, alone. There are also some relatively "low hanging fruit" for the single user case. If you like, I can try to put together a quick list now or a more reasoned and thoughtful list next week.

[sathomas]

Some initial thoughts:

• CKEditor is really strong on accessibility and, in general, probably serves as a great model.
• Probably the biggest accessibility problem with Etherpad is that it traps the keyboard user in the main textarea. Once a user navigates to the textarea, there is no way (using the keyboard) to navigate out. A first step here would be to define a special key combination (I like Esc, but other online editors seem to have settled on Alt-F10) that shifts the focus from the main textarea to the first toolbar button. From there, the user should be able to Tab to other toolbar buttons (but see below).
• Whatever the key combination(s) that support this behavior, there needs to be a way to tell the keyboard user that they exist. Perhaps a pop-up that's "visible" to screen readers, though that does introduce it's own i18n issues.
• A related issue for those sites that embed Etherpad documents in iframes is how to let a keyboard user "escape" from the iframe and get back to the main page. That will probably require some kind of plugin that enable postMessage communication between the Etherpad iframe and the main page. Since Etherpad seems to use a lot of nested iframes, this might not be as trivial as it first appears.
• Probably the number two issue is that the toolbar itself isn't currently navigable via the keyboard. I realize this is strictly a plugin issue and not a core Etherpad issue, but, of course, users don't care about that distinction. The simplest way to improve this would be to use <button> elements instead of <span> elements for the toolbar buttons.
• There are also some ARIA attributes that could be added to the toolbar to make it more accessible.

Those are probably the low hanging fruit. Beyond that, there are a couple of broader areas that hinder accessibility:

1. When rendered on the page, the document is just a simple textarea without any structure. For a couple of paragraphs, that's no big deal. For something more substantial, though, it's really challenging for a visually impaired user to "navigate" the document without benefits of structures such as headings. I don't know that it's possible to address this, but perhaps there's a way.
2. Live collaboration. This one's a real challenge. Google has obviously spent a lot of effort on making this work for Google Docs, and even they haven't been all that successful. A possible approach would be to take a look at what Google has done and see if anything is easily replicable.

[JohnMcLear]

All duly noted and added to my pad.

I have a branch with the support in now: https://github.com/ether/etherpad-lite/tree/editbar-accessibility -- Accessing and navigating the editbar with the keyboard is now possible.

My notes and to do list is at: http://john.primarypad.com/ogf-24-03-15

[JohnMcLear]

Okay guys I did what I could this week.

Accessibility enabled version of Etherpad at http://beta.etherpad.org
Docs @ https://github.com/ether/etherpad-lite/wiki/Accessibility

What have we missed? Please have a play and let me know!

cc @sathomas @MarcoZehe @MrSchism @dbolter @lizzard

[pvagner]

Heh guys I think it's amazing. I have created an example pad with my comments. Once it disappears I can restore it later from a backup.
https://beta.etherpad.org/p/pvagner%27s_test

Edit: The major issues is that I don't know how to manipulate the timeline slider. Other than this I have only found some minor issues so far.

[JohnMcLear]

@pvagner Excellent thank you so much for this!

[JohnMcLear]

@pvagner et al, this is ready for further testing.

Accessibility enabled version of Etherpad at http://beta.etherpad.org
Docs @ https://github.com/ether/etherpad-lite/wiki/Accessibility
Notes from @pvagner https://beta.etherpad.org/p/pvagner%27s_test
Todo list and completion list: #2566

[pvagner]

Hello,
Sorry for my late reply.
I apologise but I fail to make use of time slider accessibility. I don't know how to make it work so I can see multiple revisions of the same pad. Do I need to explicitly save some revisions or does it allow me to navigate all the revisions as I am editing a pad?
My testing pad at beta.etherpad.org is now gone because of possible upgrades. I do have 1 MB backup file. And I can't import it either to beta.etherpad.org nor to my own install of etherpad.
Also admin UI is working like a webpage I haven't found nothing breaking usability so far although I have only tested a few plugins up to now. My confusion with time slider is my biggest issue at this point. Otherwise I like it all.

[JohnMcLear]

@pvagner thanks, Timeslider should just be able to play back the pad... Visit

https://beta.etherpad.org/p/foo/timeslider#0

and try to use that page.. Does that work for you?

[pvagner]

Thank you for the explanation and a test pad. I have finally got the idea hopefully.
I can move back / forward a revision by pressing left / right arrow key however nothing changes when I focus the buttons and press the enter key. Also as I am moving with arrow keys I am getting no feetback that something has changed on linux with Firefox 37 and orca. I will test on Windows later.
Do you remember my comments on sliders from that testing pad. Have you looked for some keyboard usable sliders just to try comparing how these are working please?
Also I am a bit curious have you received some more comments from other disabled people via other means or am I just the lucky one speculating a lot here?

[JohnMcLear]

Hrm, well yeah regarding the timeslider experience, it's tricky because I wouldn't know what content to read to a screen reader.. I guess we could have an aria content section on the pad contents in the timeslider and make it read that contents on each forward/backwards but that's going to be a horrible UX for a screen reader?

I did look at other slider options, they don't really "fit" into what we're doing, our slider has to be designed in such a way that we will be able to overlay contents onto it in the future (a feature I want to work on) and as such we need to stick with our current solution.. It would however be useful to have an aria notification on slider move that notifies the user of their new location in the pad IE the date/time and the revision. I will add these bits to do my todo list :)

I have received some comments but until it's merged into a release branch they are only dripping in slowly!

[JohnMcLear]

This is now merged into Develop and will be released into master shortly :) Enjoy folks! Donations welcome! http://etherpad.org

[ndarilek]

Should this be available on the Sandstorm demo?

I'm blind and just tried this. The edit area is nicely accessible, but the toolbar is a bunch of unlabeled buttons/links. Arrowing through just says "button button button link clickable clickable clickable"...

Nice work so far!

[ndarilek]

Should this be available on the Sandstorm demo?

I'm blind and just tried this. The edit area is nicely accessible, but the toolbar is a bunch of unlabeled buttons/links. Arrowing through just says "button button button link clickable clickable clickable"...

Nice work so far!

Edit: Ah, I see the issue. Toolbar buttons read when tabbed through, but not when arrowed past. It might be wise to use aria-label rather than the title attribute for those, as that should address both use cases.

See this thread on the Discourse forum for more details:

https://meta.discourse.org/t/accessibility-software-and-discourse/13711/21

[JohnMcLear]

Good question, I'd check with the sandstorm guys! @kentonv

On 26 Jun 2015 17:10, Nolan Darilek notifications@github.com wrote:

Should this be available on the Sandstorm demo?

I'm blind and just tried this. The edit area is nicely accessible, but the toolbar is a bunch of unlabeled buttons/links. Arrowing through just says "button button button link clickable clickable clickable"...

Nice work so far!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1803#issuecomment-115743117.

[ndarilek]

Check out my edit below. Looks like all the controls use `title` rather than `aria-label`. They work fine if I tab between them, but not so well if I arrow through the controls outside of the edit field. Should be a pretty simple fix. Thanks!

[kentonv]

I think that Etherpad in Sandstorm should be the same accessibility-wise as Etherpad outside of Sandstorm.

Of course, Sandstorm itself introduces an additional top bar with some more buttons, and we haven't had a chance to think about accessibility yet (in fact, the UI is still pretty bad even for those who can see).

[JohnMcLear]

Hrm do you have the same experience on beta.etherpad.org ?

On 26 Jun 2015 19:17, Kenton Varda notifications@github.com wrote:

I think that Etherpad in Sandstorm should be the same accessibility-wise as Etherpad outside of Sandstorm.

Of course, Sandstorm itself introduces an additional top bar with some more buttons, and we haven't had a chance to think about accessibility yet (in fact, the UI is still pretty bad even for those who can see).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1803#issuecomment-115822729.

[ndarilek]

Sorry, the reference to Sandstorm was a bit of a red herring. I'd tried it in Sandstorm and had assumed that maybe the version Sandstorm shipped might be lagging behind the released version, but it looks pretty up-to-date. The issue isn't Sandstorm, it's just the use of the title attribute rather than aria-label. Sandstorm itself is already pretty accessible, but that's tangential to this issue. :)

[ndarilek]

Yes, because it still uses the same code. I.e.:

<button class=" buttonicon

buttonicon-insertunorderedlist" data-l10n-id="pad.toolbar.ul.title" title="Unordered
List (Ctrl+Shift+L)">

What you need is:

<button class=" buttonicon

buttonicon-insertunorderedlist" data-l10n-id="pad.toolbar.ul.title"
aria-label="Unordered List (Ctrl+Shift+L)">

Or possibly both the title and aria-label attributes. Please see the
Discourse thread. In short, screen readers don't reliably present the
title attribute because it's been abused for years. In the case of my
use (NVDA, Windows 8.1) I get two different presentations of the same
control. The first, when I tab between the buttons, is correct. The
title attribute is spoken as it should be.

The second is a bit non-standard. I can arrow through the controls as if
the webpage was a document. This is often a faster way for me to scan a
page. When you tab around, you're focused just on that particular
element. By contrast, when I arrow, I can get a larger glimpse of how
the page is laid out independent of keyboard focusability/order. In this
instance, I just hear "Button Button Button Button..." which is less
than ideal. :)

The way to fix this is to use aria-label instead of, or in addition to,
the title attribute. Any situation where this isn't the case will still
exhibit this behavior. It isn't a huge deal, but it would certainly be
very helpful.

Thanks.

[JohnMcLear]

Very useful I will do this tonight and update beta.etherpad.org for you to review :) thanks man!

On 26 Jun 2015 19:30, Nolan Darilek notifications@github.com wrote:
Yes, because it still uses the same code. I.e.:

What you need is:

Or possibly both the title and aria-label attributes. Please see the
Discourse thread. In short, screen readers don't reliably present the
title attribute because it's been abused for years. In the case of my
use (NVDA, Windows 8.1) I get two different presentations of the same
control. The first, when I tab between the buttons, is correct. The
title attribute is spoken as it should be.

The second is a bit non-standard. I can arrow through the controls as if
the webpage was a document. This is often a faster way for me to scan a
page. When you tab around, you're focused just on that particular
element. By contrast, when I arrow, I can get a larger glimpse of how
the page is laid out independent of keyboard focusability/order. In this
instance, I just hear "Button Button Button Button..." which is less
than ideal. :)

The way to fix this is to use aria-label instead of, or in addition to,
the title attribute. Any situation where this isn't the case will still
exhibit this behavior. It isn't a huge deal, but it would certainly be
very helpful.

Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1803#issuecomment-115825669.

[JohnMcLear]

having some issues with this will try finish over weekend

---

From: Nolan Darilek [notifications@github.com]
Sent: 26 June 2015 19:30
To: ether/etherpad-lite
Cc: John McLear
Subject: Re: [etherpad-lite] Improve accessibility for blind people and other users of screen readers (#1803)

Yes, because it still uses the same code. I.e.:

What you need is:

Or possibly both the title and aria-label attributes. Please see the
Discourse thread. In short, screen readers don't reliably present the
title attribute because it's been abused for years. In the case of my
use (NVDA, Windows 8.1) I get two different presentations of the same
control. The first, when I tab between the buttons, is correct. The
title attribute is spoken as it should be.

The second is a bit non-standard. I can arrow through the controls as if
the webpage was a document. This is often a faster way for me to scan a
page. When you tab around, you're focused just on that particular
element. By contrast, when I arrow, I can get a larger glimpse of how
the page is laid out independent of keyboard focusability/order. In this
instance, I just hear "Button Button Button Button..." which is less
than ideal. :)

The way to fix this is to use aria-label instead of, or in addition to,
the title attribute. Any situation where this isn't the case will still
exhibit this behavior. It isn't a huge deal, but it would certainly be
very helpful.

Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1803#issuecomment-115825669.

[JohnMcLear]

Resolved #2711