Purpose

This thread is used to compare and discuss the accessibility of popular WYSIWYGs that might be candidates for inclusion in Drupal core. Right now, that pretty much means a comparison between CKEditor and tinyMCE. Other WYSIWYGs are not exactly out of the running at this point, but let's try to keep this issue on discussing accessibility merits only (on these editors or others) and not on which WYSIWYG we should use overall.

Process

In order to assess TinyMCE and CKEditor we need to test two things;

1. Are the UIs of these editors accessible?
2. Do the editors generate accessible markup?

In order to do this testing we will need to know:

1. Which version of the libraries are we currently considering?
2. What features are we currently considering (e.g. headings, tables, bold, italic, etc.)

Obviously the features can be configured after a user installs D8, but let's look at a fairly wide set of editing features, this will allow us to make a
more informed decision if things are close.

Deliverable

A recommendation of a WYSIWYG editor that both provides an accessible (WCAG 2.0 AA) compliant UI, and which provides the ability to generate WCAG 2.0 AA compliant markup.

The recommendation should come with a rationale and a list of areas in which the editor is not WCAG 2.0 AA compliant. A list of compliance problems in alternative editors should also be provided, to assist with decision making, as accessibility is not the lone criteria for editor selection.

Related

Two posts from #1094094: WYSIWYG in core: Call for volunteers!:

mgifford:

One of the big accessibility problems with sites comes through bad WYSIWYG editors. I'm interested in helping to see that when we get a WYSIWYG in core it produces clean HTML & can be edited effectively through assistive technology.

Everett Zufelt

However, I echo @mgifford, WYSIWYG creates * many * accessibility issues. My guess is that the only WYSIWYG library worth considering, from an accessibility perspective, is CKEditor.

Comments

quicksketch’s picture

My guess is that the only WYSIWYG library worth considering, from an accessibility perspective, is CKEditor.

I'm not sure why you would have that particular perception. Some users have expressed tinyMCE specially as being better (#241753-100: Integrate tinyMCE better with IMCE - Simple solution), and more recent versions of tinyMCE have keyboard based navigation (http://www.tinymce.com/tryit/accessibility.php and http://www.tinymce.com/wiki.php/Accessability) as well as ARIA compliance (http://ephox.com/events/ephox-brings-accessibility-compliance-tinymce).

Assuming CKEditor also has taken such steps, I think more research is needed to see if one has any advantage over the other in this area.

Everett Zufelt’s picture

Issue tags: +Accessibility

@quicksketch

My comment re: CKEditor was strictly from personal experience using implementations, and not from thorough testing, I should have been more clear.

We need to test two things;

1. Are the UIs of these editors accessible?
2. Do the editors generate accessible markup?

In order to do this testing we will need to know:

1. Which version of the libraries are we currently considering?
2. What features are we currently considering (e.g. headings, tables, bold, italic, etc.)

Obviously the features can be configured after a user installs D8, but let's look at a fairly wide set of editing features, this will allow us to make a more informed decision if things are close.

klonos’s picture

...subscribing.

We now have editable issue summaries, so please edit/update the summary along with any of your comments: Issue summary standards

@Everett Zufelt: your points seem to fit the "Remaining tasks" of the summary.

Everett Zufelt’s picture

Issue summary: View changes

Providing direction and required deliverable for the task.

Everett Zufelt’s picture

Updated issue summary.

mgifford’s picture

Agreed. Can't just look at the spin that they put out.

Hanno’s picture

These two criteria resemble ATAG 2.0 part A and part B.

We could use the ATAG criteria (http://www.w3.org/TR/ATAG20) to compare wysiwyg editors. Part B:

B.1. Fully automatic processes must produce accessible content
B.1.1. Ensure automatically specified content is accessible
B.1.2. Ensure accessibility information is preserved
B.2. Authors must be supported in producing accessible content
B.2.1. Ensure accessible content production is possible
B.2.2. Guide authors to produce accessible content
B.2.3. Assist authors with managing alternative content for non-text content
B.2.4. Assist authors with accessible templates
B.2.5. Assist authors with accessible pre-authored content
B.3. Authors must be supported in improving the accessibility of existing content
B.3.1. Assist authors in checking for accessibility problems
B.3.2. Assist authors in repairing accessibility problems
B.4. Authoring tools must promoted and integrate their accessibility features
B.4.1. Ensure the availability of features that support the production of accessible content
B.4.2. Ensure that documentation promotes the production of accessible content

Everett Zufelt’s picture

@Hanno

We likely don't have resources to do this properly for WCAG 2.0, I don't really like the idea of bringing ATAG 2.0 into this unless some others step up to assist with, or fund, the review.

BJ___’s picture

delete me

quicksketch’s picture

@quicksketch Is this what you mean by Accessibility ? Or do you mean well formed / Accessible HTML ?

The terms "accessibility" and "usability" are unfortunately entirely separate concepts in Web-jargon. This issue is about "accessibility", which means that the editor must be usable without the mouse (keyboard-only navigation) or through use of a screen-reader. "Usability" means having a nice interface that is easy to understand. I'm simplifying the concepts a bit but that's the general idea.

It might be unpopular to say but I think that having an WYSIWYG editor that is easy to use might be worth some technical compromises.

I agree here also. We may need to make some compromises in accessibility in order to get a highly "usable" system for the majority of our end-users, but obviously we'd like to make the WYSIWYG we put into core as accessible as possible. Let's keep this issue focused on accessibility which is much easier to have quantitative answers for than usability, which may be subjective in a lot of places.

Everett Zufelt’s picture

Any ideas on versions of TinyMCE ' CKEditor being considered?

quicksketch’s picture

Any ideas on versions of TinyMCE ' CKEditor being considered?

I would assume that we'd use the latest version of any WYSIWYG, unless there's some big release on the horizon that we want to target instead. Do you have a reason for preferring a specific version?

Everett Zufelt’s picture

No reason for preferring, but it makes sense only to test what is currently being considered. If there is some compelling reason based on other criteria to prefer one version over another I'd like to know that so we can limit resources required for testing.

Hanno’s picture

ATAG is meant for editors and this makes it easier to compare. If we don't have the resources to check for ATAG ourselves, it might be interesting to ask the maintainers of tinyMCE and CKeditor.
If we choose for one or the other, planned improvements for accessibility are interesting to know as well, as we become depended on these editors and maintainers in the process of making Drupal accessible (ATAG/WCAG). So I would prefer we take into account their next versions/plans.

Check of tinyMCE compliance on ATAG 2.0 can be found here:
http://jan.idrc.ocad.ca/public/atag/implementation_report_rev5.html

Check of CKeditor compliance on WCAG 1.0 can be found here:
http://docs.cksource.com/CKEditor_3.x/Accessibility_Compliance/Web_Conte...

mgifford’s picture

We're really not looking at their accessibility in the last release. The dev release might be an indication, but this isn't something that will be released for another year or so, so have to look ahead. Do either have an accessibility community behind them like Drupal does?

franz’s picture

subscribing

Hanno’s picture

Is someone already in contact with one of these communities on this issue?

mgifford’s picture

Not that I am aware of. Perhaps I can find a good contact via twitter.

Hanno’s picture

good idea. we can also post a support request in their issue tracker?

mgifford’s picture

Absolutely. Please do so and point back here to this issue.

Hanno’s picture

FYI: The Belgian organisation for accessibility AnySurfer has just published a blogpost about a comparison between CKeditor and tinyMCE: http://blog.anysurfer.be/2011/10/17/geschikte-wysiwyg-editor/

Everett Zufelt’s picture

And the English version from Google Translate: http://translate.google.ca/translate?hl=en&sl=nl&u=http://blog.anysurfer...

In short it appears that the reviewer found that both CKEditor and TinyMCE work well, but that CKEditor, being somewhat better, works best as far as accessibility goes.

One point raised is that CKEditor uses the same set of keyboard shortcuts across OSs and browsers, whereas TinyMCE does not ensure that shortcuts stay the same across OSs.

klonos’s picture

...might wanna check the URL in that link of yours Everett ;)

effulgentsia’s picture

As per the discussion in #1260052: Candidate WYSIWYG editors, I think it would be great if we could also evaluate Aloha for accessibility. @mgifford asked the question in http://getsatisfaction.com/aloha_editor/topics/how_accessible_is_aloha, but there've been no responses as of yet.

effulgentsia’s picture

Hm. Actually, looks like Aloha's move from ExtJS to jQuery UI is still in-progress: https://github.com/alohaeditor/Aloha-Editor/issues/55. I suspect it's not worth our time evaluating its accessibility under ExtJS, since I don't think it's a candidate for inclusion in core until it switches to jQuery UI, and any accessibility review would need to be redone at that time. Pity.

amaree’s picture

Hi all,

Ok I have a prelimary report though it is not that big at the momment, I also have done a quick cheat sheet so to speak about what features they support and what they do not, maybe I can add these somewhere? If not on Drupal.org then I will add to my own blog and people so people can download etc. This will be a growing document as for a client I am currently evaluating Drupal and WCAG2.0 AA compliance.

To state I will say, accessiblity is an eco system, it is of two things, 1 is the editor as an authoring tool, the 2 is the output of the editor. Now CKeditor and TinyMCE both meet WAI-ARIA compliance and WCAG 2.0 A as an authoring tool so this means that people with assistive technologies can use them yes so check there. The other issue though is that as of yet neither of them create verfied HTML output and accessible output without 1, limiting the feature set (for example neither can allow you out of the box to create an accessible or W3C table, there is no way to add table headers for example)

Also its about Drupal core itself, at the momment for Drupal7 I am having to rewrite pretty much all standard tpl files in core to add features like WAI-ARIA roles, HTML5 tags and general WCAG 2.0 AA needs. Also we have to write a bunch of wrapper modules in order to make modules etc accessible. So hence why I say it is an eco-system. So if we get an editor that meets the authoring needs of assistive technology but its output fails well that means basically assistive technology people can create content but not necessarily read it well? Some things to think about?

As we have a long lead time for Drupal 8.0 I also feel that the aim should be for WCAG 2.0 AA compliance not just A (my thoughts only keen to see what others think)

amaree’s picture

Oh also niether CKEDitor or TinyMCE editor comply with ATAG 2.0

Anna_CKSource’s picture

As suggested by quicksketch, I am re-posting some accessibility links for CKEditor here.

Accessibility has always been a crucial issue at CKEditor, here are some resources from our side that I can recommend for a start:
http://docs.cksource.com/CKEditor_3.x/Users_Guide/Accessibility
http://ckeditor.com/blog/CKEditor_and_WAI-ARIA_means_Usable_Accessibility

Keyboard shortcuts are documented here: CKEditor Users Guide - Keyboard Shortcuts.

It is also worth of mentioning that CKEditor officially supports JAWS and High Contrast mode, as explained in the CKSource Graded Browser Support article.

Here is the current queue of open accessibility issues.

The easiest and quickest way to report any and all accessibility issues is to go to our Development site, create a ticket, and set the Component field to Accessibility. If the issue only occurs in the Drupal integration, please be so kind as to mention it in the ticket.

See this article for ticket specs if you need any tips on how the tracker works.

If you have any specific questions about our accessibility support, do not hesitate to contact me or wwalc directly.

Hanno has already given us an idea for an accessibility improvement (see ticket #7987: Implement Language toolbar button to support WCAG 3.1.2 Language of Parts) and we have just created a new CKEditor plugin to support this feature. You are most welcome to give it a try and provide your feedback.

It would be great if you could have a look at the list of accessibility issues quoted above and comment on the ones that might be particularly important for the Drupal community (or suggest some further improvements, too!). We will be working on the next CKEditor release soon so we might consider adding some of these to the roadmap in order to progress this issue. Your feedback is most welcome!

quicksketch’s picture

Thanks for the references Anna_CKSource! If you're in touch with wwalc, you may have already connected about my primary concern with CKEditor, which I documented here: #1286004-1: Research/Build suitable captioning system for inline images and in this issue over in the Caption Filter queue: #696734-19: Integration with CKEditor or WYSIWYG?. That issue isn't accessibility-related, but I just want to make sure it's raised as a serious concern.

Anna_CKSource’s picture

Thanks, quicksketch! I am aware of the issue and I know that the developers are already working on this, so you can be sure it will be fixed sooner rather than later. Any comments with regard to the patch provided by wwalc are most welcome! Likewise any other purely accessible-related suggestions, too, to stay in line with the thread subject ;).

realityloop’s picture

@amaree are you happy to share the updated D7 tpl files with WAI-ARIA roles added?

mgifford’s picture

That would be great to see the work that @amaree was talking about.

There's similar work that may already be compiled in this distro:
https://github.com/wet-boew/wet-boew-drupal

Know there was some improvements to the WYSIWYG they are using.

mgifford’s picture

Issue summary: View changes

Correcting heading levels

mgifford’s picture

Status: Active » Closed (fixed)

Closing this issue. CKEditor has been chosen.