[WG: Accessibility] CKEditor 3.2
Ken Petri
petri.1 at osu.edu
Mon Mar 8 14:55:18 PST 2010
Hi Eli,
Feel free to log that problem with CK. They many consider it a "feature,"
though I'm not sure what rationale they'd give....
Re: markItUp!, try shift-tabbing out of the top of the editor pane. I
couldn't get it to work. But the fact that the editor is so easily skinnable
and the syntax for writing to target new markup languages is so
straight-forward, I doubt it would be a problem. One thing I would advise is
to make a link that allows a screen reader user to jump straight into the
editor window, so she doesn't have to deal with the toolbar cruft (though
the shortcuts in it may be useful, so long as the screen reader has VPC
Cursor off/pass through on).
It's really nice to see Sakai has such a strong and committed team working
on accessibility.
Best,
ken
On Mon, Mar 8, 2010 at 5:44 PM, Eli Cochran <eli at media.berkeley.edu> wrote:
> 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/c4fb39ea/attachment-0001.html
More information about the accessibility
mailing list