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
Comment #1
quicksketchI'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.
Comment #2
Everett Zufelt CreditAttribution: Everett Zufelt commented@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.
Comment #3
klonos...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.
Comment #3.0
Everett Zufelt CreditAttribution: Everett Zufelt commentedProviding direction and required deliverable for the task.
Comment #4
Everett Zufelt CreditAttribution: Everett Zufelt commentedUpdated issue summary.
Comment #5
mgiffordAgreed. Can't just look at the spin that they put out.
Comment #6
Hanno CreditAttribution: Hanno commentedThese 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
Comment #7
Everett Zufelt CreditAttribution: Everett Zufelt commented@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.
Comment #8
BJ___ CreditAttribution: BJ___ commenteddelete me
Comment #9
quicksketchThe 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.
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.
Comment #10
Everett Zufelt CreditAttribution: Everett Zufelt commentedAny ideas on versions of TinyMCE ' CKEditor being considered?
Comment #11
quicksketchI 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?
Comment #12
Everett Zufelt CreditAttribution: Everett Zufelt commentedNo 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.
Comment #13
Hanno CreditAttribution: Hanno commentedATAG 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...
Comment #14
mgiffordWe'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?
Comment #15
franzsubscribing
Comment #16
Hanno CreditAttribution: Hanno commentedIs someone already in contact with one of these communities on this issue?
Comment #17
mgiffordNot that I am aware of. Perhaps I can find a good contact via twitter.
Comment #18
Hanno CreditAttribution: Hanno commentedgood idea. we can also post a support request in their issue tracker?
Comment #19
mgiffordAbsolutely. Please do so and point back here to this issue.
Comment #20
Hanno CreditAttribution: Hanno commentedFYI: 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/
Comment #21
Everett Zufelt CreditAttribution: Everett Zufelt commentedAnd 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.
Comment #22
klonos...might wanna check the URL in that link of yours Everett ;)
Comment #23
effulgentsia CreditAttribution: effulgentsia commentedAs 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.
Comment #24
effulgentsia CreditAttribution: effulgentsia commentedHm. 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.
Comment #25
amaree CreditAttribution: amaree commentedHi 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)
Comment #26
amaree CreditAttribution: amaree commentedOh also niether CKEDitor or TinyMCE editor comply with ATAG 2.0
Comment #27
Anna_CKSource CreditAttribution: Anna_CKSource commentedAs 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!
Comment #28
quicksketchThanks 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.
Comment #29
Anna_CKSource CreditAttribution: Anna_CKSource commentedThanks, 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 ;).
Comment #30
realityloop@amaree are you happy to share the updated D7 tpl files with WAI-ARIA roles added?
Comment #31
mgiffordThat 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.
Comment #31.0
mgiffordCorrecting heading levels
Comment #32
mgiffordClosing this issue. CKEditor has been chosen.