[WG: Accessibility] CKEditor 3.2

Sun Mar 7 12:15:51 PST 2010

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"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20100307/3d62f269/attachment.html 