[WG: Accessibility] CKEditor 3.2
Eli Cochran
eli at media.berkeley.edu
Mon Mar 8 14:44:49 PST 2010
Ken,
Thank you so much for taking CKEditor for such a thorough test drive -- definitely more than "a spin". Very helpful.
We should log your "one major drawback ... no way to get out of the toolbar" as a bug with the CKEditor folks. Would you like to do that? If not, I'm happy to.
I appreciate your comments about text-based markup languages being a superior experience for screen reader users. I would have to agree. And thanks for the suggestion of markItUp. [1] Nice product. I especially like that it supports multiple markup languages. Switching to something like markItUp for the Sakai 2 line is too radical a switch from FCKeditor but something that we should consider for Sakai 3.
Thanks,
Eli
[1] http://markitup.jaysalvat.com/home/
On Mar 7, 2010, at 12:15 PM, Ken Petri wrote:
> Hi Eli,
>
> Taken for a spin. Here are my subjective impressions. Your mileage may vary (but I think I'm hitting pretty close to the mark).
>
> Conclusion: CKEditor is now better than TinyMCE with regard to accessibility. I tested both in NVDA with Firefox and in IE with JAWS 11. When in the editor, it was necessary to be in pass-through mode/have the Virtual PC Cursor off.
>
> The one major drawback to CKEditor is that there is no way to get out of the toolbar and back into the editor area without issuing a command/activating a button--why not just another Alt + Shift + F10 to toggle between the panes? By contrast, TinyMCE allows a Alt + Shift + Z to bump you back into the editor. And it should be noted that neither editor functions very reliably when in full-screen mode--you tend to lose track of where the cursor is.
>
> On all other scores, CK is in the lead or equal to Tiny. Unlike Tiny, CKEditor:
> toolbar behaves like a toolbar, accepting arrow keys (as well as tab key presses)
> accommodates Windows high-contrast mode, replacing the toolbar icons with text (Tiny becomes unusable in high-contrast mode)
> dropdown menus are easier to navigate with the screen reader
> right-click menu was available via Shift + F10 (which is a standard keystroke--you can also use the Windows menu key, if the keyboard has one--this does not work in Tiny)
> editor pane clearly announces itself as such when focused with with the screen reader
> Unselectable menu items are announced as such when focused with the screen reader
> "path" region is announced as such when focused with the screen reader
> dialogs (that I tested) are properly marked up and escapable with standard keystrokes that return focus to the editing area (Tiny's are properly marked up and focused but don't return focus properly)
> Overall, CK feels more polished and modern in its approach to accessibility. It's keyboard accessibility is very much like a desktop application. Its screen reader accessibility is, in my opinion, superior to Tiny.
>
> General caveat for all of the above: WYSIWYG in-browser JavaScript-powered editors are a major pain in the ass to use with a screen reader, regardless of screen reader/browser combination. As I have noted before on this list, if your goal is functional accessibility, make the editor optional and have as an available alternative a text area or similar that takes Markdown, WikiText, or Textile and parses it into HTML.
>
> Let me give a concrete example of why WYSIWYG is "problematic"/sucky: If I'm in a WYSIWYG, regardless of which one, and I want to style some text, so I've gone through the relatively laborious process of selecting the text and navigating/jumping to the toolbar, looking through all of its options, and finally setting a style on that selected text, how, then, do I determine whether or not that style "took?" Answer: I have to jump to the "path" bar and navigate through its representation of the document tree and hope beyond hope that those three nested spans that surround that bit of text I've just styled actually represent the styling I want. Or, worse, I go into the source view and try to determine the styling from raw HTML markup.
>
> This is huge work. And if you think that sounds hard, try editing a table in an in-browser WYSIWYG with a screen reader. It is nearly impossible.
>
> By contrast, if the styles are pre-defined and I know their names, adding a class in Textile is very simple--just typing a couple of characters to start and end the style block and typing in the name of the style. Creating a table is also relatively simple--typing cell contents, pipes to separate columns and rows, and asterisks for identifying table headers (depending on your flavor of Textile). And making or editing plain old HTML headings, links, and lists is trivially simple--I can instantly tell in the editor if a list is a list, a heading a heading, bold is bold, etc.
>
> I realize there will be overhead for the parsing operations on a Textile-type set up, but in the long run you will make your screen reader reliant users much happier. You might have a look at Jay Salvat's MarkItUp. It has a problem with reverse-tabbing out of the editor, but other than that seems pretty solid. MarkItUp might satisfy both screen reader users and users who just don't like WYSIWYG.
>
> Best,
> ken
> -------------------------------------------------------
> Ken Petri
> Program Director
> OSU Web Accessibility Center
> 102D Pomerene Hall
> 1760 Neil Avenue
> Columbus, Ohio 43210
> Phone: (614) 292-1760
> Fax: (614) 292-4190
> mailto:petri.1 at osu.edu
> -------------------------------------------------------
>
>
> On Mon, Mar 1, 2010 at 1:44 PM, Eli Cochran <eli at media.berkeley.edu> wrote:
> This is a follow up to a thread that started back in November.
>
> At that time there was discussion about upgrading Sakai to use CKEditor 3.0.1 instead of FCKEditor. CKEditor is a significant upgrade to FCKEditor, primarily in the area of accessibility.
>
> Today I noticed that CKSource released another upgrade on Feb. 25th, CKEditor 3.2. This version continues to expand the accessibility of CKEditor by support WAI-ARIA.
>
> http://ckeditor.com/blog/CKEditor_3.2_released
>
> Does someone in our accessibility community have time to take it for a spin to validate the accessibility?
>
> Thanks,
> Eli
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
>
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
. . . . . . . . . . . . . . . . . . .
Eli Cochran
user interaction developer
ETS, UC Berkeley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20100308/bdf7a6c1/attachment.html
More information about the accessibility
mailing list