I tested demo.sparkdrupal.com alpha5 with JAWS13 / FF14, NVDA2012.2.1/FF14 and VoiceOver/Safari on Lion. None of these combinations could edit the contenteditable region of the DOM. JAWS and NVDA after intering forms (interative) mode could not even read the content of the region.

Some other WYSIWYGs like CKEditor and TinyMCE use contenteditable, but in the background, while editing is still in an iframe. The accessibility of these editors is improved. Using a screen-reader you can read and edit the content, even if you don't get a live sense of the semantics (list/headings/etc) applied to any portion of the content.

Comments

Project:Spark» Edit
Assigned:Unassigned» Wim Leers

I started googling to learn more about this problem.

Guess what? This issue was second on Google… Your blog post was fifth. That's not very promising.

I found an article that suggests it might be impossible. For Aloha Editor to work, it needs to manage the user's selected text: first the user selects the text, then the user can click on e.g. the "Bold" button to bold the selection. Aloha Editor has to add some mark up to the previous selection because the browser moves focus to the WYSIWYG toolbar.
That article says the following:

It’s not just screen readers either, screen magnifiers will move the screen along to keep up with the caret, ensuring the user can see what they’re typing. If the caret is fake, none of these features will work and the editor becomes inaccessible.

Am I jumping to conclusions incorrectly? What are your thoughts?

I posted a message to the WebAIM mailing list http://webaim.org/discussion/mail_message?id=21097 Hoping for some helpful responses.

No responses yet. Should we interpret that as bad news?

This is an example.

See if the above renders

Should it be possible to edit (obviously not save) the first paragraph in comment #4 above? contenteditable seems not to be filtered out on d.o :)

I cannot edit the content, but admittedly know little about contenteditable. Can you post a simple markup example that would be editable w/o assistive technology if the above is not working?

#5: HAH! :D That is indeed working! I guess we should make d.o's filtering more strict :)

Also: CKEditor just announced a beta of version 4 of their software, which *also* supports in-place editing ("true WYSIWYG"). They announced it on August 22, the day after we demoed it at DrupalCon… Could you maybe try their demo as well? If any WYSIWYG editor has their accessibility stuff done right, it's probably CKEditor. And if CKEditor can pull it off, then so can Aloha Editor.

Anxiously awaiting your results… :)

I found 5 editable text inputs on the CKEditor demo page, I was able to edit them.

There are 8, but that is at least progress. Looks like the Aloha Editor folks can learn from this.

Concerning that I can only find 5, but agreed on progress.

I've reported this to the Aloha Editor guys, in this comment on the main accessibility issue for Aloha Editor on GitHub.

I've also just pinged them by e-mail, and connected you at the same time, Everett. :)

Project:Edit» Aloha Editor
Version:7.x-1.x-dev» 7.x-2.x-dev

In case it's not clear by scanning this issue, this is the relevant AE issue on GitHub: https://github.com/alohaeditor/Aloha-Editor/issues/590

They're now working on an alternative UI that should make it significantly easier to be fully accessible: https://github.com/alohaeditor/Aloha-Editor/issues/747.

@Wim do you know if there are any demos available, or can you please post here when one exists?

@Everett Zufelt: you can get it up and running by checking out the proper branch via git and going to the demo. However, there has been no work done yet on the actual a11y (I learned that abbreviation from you — thanks! :D) improvements. I will keep you posted. In the mean time, please subscribe to Aloha Editor issue 747 — I've also just posted a comment there, asking for clarifications.

@Everett Zufelt: Forgot to say: if you want, I can set up such a demo site for you, but I'm afraid it won't be of much use. I'm 99% certain it'd actually be an a11y regression ATM, but it looks like it will be a zillion times easier to do it right in this UI architecture than in the previous one.

I tried out the CKEditor demo with NVDA-2012.2.1.

Chrome doesn't work at all I'm afraid - it says "blank" when changing cursor position (it should say the letter after the selection) and it says "no selection" when pressing the key combination for speaking the current selection.

Firefox works a little better. The first two editables are heading elements, and they seem to work without problems as far as I could tell. The div elements on the other hand didn't work - it doesn't say anything when changing cursor position and I can't make it speak the current selection either (it just says "selected" and nothing more).

I reproduced this behaviour with a bare-bones html page that only contains contenteditable header and div elements (no Aloha or CKEditor).

I suppose this would be the first issue to tackle?

I didn't yet try out any toolbar interaction. I wonder how you would use the toolbar with NVDA? Except for shortcuts (e.g. CTRL-b for bold) I don't see any way to use the toolbar.

This is my first time using a screen reader, so I would be greatful for any tips.

@Deliminator: well, great to see a work in progress...

If you point me to an online demo, I will be more than happy to do some tests for you (I am blind and I use a screen reader on a daily base).

But, unfortunately, I don't know very much about javascript, so I am afraid I cannot help you finding any good solution...

Thanks for your help @falcon03.

Can you tell me what screen reader and browser combinations you usually use?

Also, can you reproduce my observations with your screenreader on the following test page: http://aloha-editor.org/a11y.html

The page contains a contenteditable heading element and a contenteditable div element. There is no Aloha or CKEditor on this page. As I mentioned in my previous comment, with Firefox, I expect the heading element to work without problems, but the div element below it should not work at all.

@Deliminator: you are more than welcome... :-)

Generally, I use Mac OS X 10.8 (mountain Lion) as my O.S., Safari as browser and Voiceover (builtin every macintosh) as my screen reader.
However, on my Windows environment I use Internet explorer 8 or (better) Mozilla Firefox (the latest available version) with NVDA 2012.2.1 as my windows screen reader. But, unfortunately, I have to say that we have to deal also with jaws, the most used windows screen reader (that I do not use regularly as I did in the past).

I've just done some tests with my mac os X and I noticed that the "div" element was hidden to the screen reader (if I hadn't known that it was there I would have thought that after the "heading" element there was nothing)
In the heading element, I was able to select a part of the text and copy it to the clipboard receiving feedback from Voiceover.

But Voiceover didn't give me any feedback to let me understand when I was typing or deleting some characters, paragraphs or words (even if it's set to do so).

In my opinion the main problem is that a screen reader doesn't see "Contenteditable" elements as text areas; and, due to this, we have to deal with lots of accessibility issues (but, of course, I can be wrong as I am not a JQuery expert).

Finally (sorry for that) I linked a CKEditor demo page with an instance of that (I know competitor) editor that I think as solved lots of accessibility issues; maybe you could look at that code to find a solution (I hope I didn't make a mistake linking a CKEditor demo)....
http://nightly-v4.ckeditor.com/3645/samples/replacebyclass.html

BTW, If needed I'll do some windows-based tests later...

Thank you for your feedback @falcon03.

I have tested the CKEditor demo at the link you provided. The demo uses
an iframe that contains a contenteditable body element. I tested this in
isolation, and it seems that the body element, in addition to heading
elements as already mentioned, and also paragraph elements can be made
contenteditable without problems.

Elements that don't work well are div, section and article elements.

I have tested JAWS+Firefox and NVDA+Firefox and both don't work well
with div elements.

Haymo tested VoiceOver and it does appear to work but as you said, it
doesn't give feedback when typing and deleting text. Adding the role
attribute with a value of "textarea" seems to solve that problem. I have
updated the example at http://aloha-editor.org/a11y.html to include the
role attribute.

Currently, the best way to go would be with an iframe and
contenteditable body approach. But maybe we can find something better?

A very significant part of the reason we chose Aloha Editor in the first place is because it did *not* use iframes. This has several advantages: better performance, better compatibility with mobile devices (I'm not sure if that still holds true though) and most significantly: the style of the main page itself is inherited/applied. When using an iframe, one has to resort to dirty tricks to ensure the styling of the text being edited has the exact same styling as it would have without the iframe.
If we're going the iframe route, it's an absolute requirement that the iframe is 100% unnoticeable (not a single pixel may look different when comparing the with-iframe vs. without-iframe cases).

Hi Deliminator,

I tested again the updated demo, but I am sorry to say that nothing has changed for me: Voiceover goes on not seeing the element as a textarea and not giving feedback when typing/deleting words, characters and paragraphs. (I am still not able to see the text wrapped in a text area)..

When interacting on a CKEditor body instance I am able to see it recognized as "application" (I think due to the ARIA Role applied, but I am not sure). And it doesn't happen the same with the demo you provided, unfortunately (I don't know if this is the cause of our issues).

Assuming that blind people don't care much about pixel-identical visual appearance, we could offer two modes - one with iframe that works great with screen readers, and one without.

This is not necessarily the only way to do it. I will continue my testing - maybe I can come up with an alternative.

Thanks @falcon03 for trying out the demo. I will talk again with Haymo, since I don't have VoiceOver myself.

@deliminator:
well, generally I disagree with using two different approaches for blind and sighted users...

The main question is: how should we switch between the two modes?
If the switch can be done automatically then I could think to agree with you; but, if the switch is manual or based on a particular setting then I won't agree at all...
At this time, however, I would ask you if you can implement contenteditable into an iFrame and provide an onLine demo (or give me instructions on how to do this), so that we can test if this could be a solution or not...

@Wimleers: could I ask what differences can get a sighted using an editor wrapped into an iFrame or not wrapped into it?

@falcon03
My apologies, VoiceOver requires the role "textbox" not "textarea". I fixed the demo accordingly.

After some experimenting I discovered that NVDA works with contenteditable div elements if you set the role="application". JAWS on the other hand needs the role="textbox" to work around a bug that causes the voice to sometimes announce the letter before the cursor and sometimes the letter after the cursor.

I added a a second editable div element to the demo - the first works with JAWS, the second with NVDA. I also added Aloha to the demo, but with the new a-la-carte UI instead of the standard floatingmenu.

Since the "textbox" role required by JAWS and VoiceOver conflicts with the role "application" required by NVDA, I will experiment a little with nesting elements with both roles.

There is something that I have been wondering about: none of the screen readers announce any text formatting - bold text for example. There is no way to determine with the screen reader whether there is any formatted text in a contenteditable. @falcon03 do you have any ideas? Is there some screen-reader specific functionality that helps here?

Another question from Haymo: do you prefer buttons to be announced as "Make selection bold" or "bold button" or just "bold"?

This is bold and this is strong text.

Using JAWS JAWSKey + 5 reads text attributes, doesn't seen to help in FF 15 / JAWS 13.

@deliminator: I am very happy to read your comment...

Unfortunately I don't have my test-environment now, so I will test the demo this afternoon (or this evening if not possible this afternoon).

If you select a certain portion of text (a single character can be enough) you can know the text formatting by pressing "Insert + F" (with Jaws or NVDA) or "Vo + T" (Vo is equivalent to Control + Option) with Voiceover.

For buttons, I would really enjoy them if they were created with the "button" html 5 tag or they were links with the "button" role. Their label should be as short as possible (for instance "bold"); at the same time I would assign to them a longer help text (if buttons are created as links with the role = "button" attribute I think you could use the Title attribute; for instance the help text for the "bold" button could be "Makes selection bold").

BTW, have you tried assigning the two roles to the same region (e.g.

@falcon03 thanks for your hints. I tried "VO+T" and it just tells me that I have selected content by saying "selected". What we would like to know is the formatting of content. Or what is the best strategy to expose a certain formating if you have a certain selection? Example code: Some <b>content [is] bold</b> and some not. The [] should show the selection.

Thank you.

I have updated the demo again. All three editables now have the role "textbox" and are wrapped with a div that has the role "application". This seems to work well with JAWS and NVDA (and I assume VoiceOver as well). It also works in both Chrome and Firefox. I didn't test IE yet.

The insert + F combination seems to work in both JAWS and NVDA.

I wonder though if insert + F is the best we can do. I put some bold text into both editables. In the first editable I set the "aria-label" attribute to the value "bolded". NVDA now speaks the label when the cursor is moved into the bold formatted text in the first editable. Problem with this is that when the cursor is moved into the sentence, NVDA only speaks the text before the bold element.

The example http://aloha-editor.org/a11y.html works also for me on voice over, with basic formatting. The menu still needs some improvements.

@deliminator, @draftkraft: yeah, things are better now...

However, I still have some issues using Voiceover,

  • when I reach the last row of a textarea and I keep pressing the "down arrow", I hear a particular sound that gives me this information. Unfortunately this is not happening with the demo.. (while the first row does this perfectly);
  • Scrolling the content of the textarea with the vertical arrows I cannot hear feedback for empty rows;
  • After pressing "enter" to create an empty line, mysteriously Voiceover stops giving any feedback using vertical arrows (even for rows containing text);

Version:7.x-2.x-dev» 8.x-2.x-dev

Version:8.x-2.x-dev» 7.x-2.x-dev

Thank you @falcon03 for your efforts. I really appreciate your feedback.

I currently don't have access to VoiceOver. I can only test with JAWS or NVDA (or any other windows or linux screen reader).

With NVDA, when reaching the last row and pressing "down arrow", the last row is spoken. Empty paragraphs are announced as "paragraph editable blank". Empty lines inside a paragraph (separated by "br" elements) are announced as just "blank".

With JAWS, when reaching the last row and pressing "down arrow", nothing is spoken. Empty paragraphs and lines are announced as "blank".

I may get the opportunity to test VoiceOver tomorrow.

Version:7.x-2.x-dev» 8.x-2.x-dev

Restoring version; I assume that was a cross-post.

One concern I have about using application mode, which I am sure we can overcome, is that it is hard for a screen-reader user to get out of the editor.

How will we allow screen-reader users to easily exit the editor? Will tabbing out work? If so, do users lose the ability to use tab for some alternative intended purpose?

Component:Code» Accessibility