[Building Sakai] [WG: Accessibility] CKEditor 3.2

D. Stuart Freeman stuart.freeman at et.gatech.edu
Tue Mar 9 12:22:35 PST 2010


MarkItUp looks really cool for "power users" too.  I personally prefer to
use well known markup languages over hunting through buttons to do
markup, especially when I know how easily I could do something in html
but I can't find the button for it.

On Mon, Mar 08, 2010 at 02:44:49PM -0800, Eli Cochran 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] [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:[2]petri.1 at osu.edu
>      -------------------------------------------------------
> 
>      On Mon, Mar 1, 2010 at 1:44 PM, Eli Cochran <[3]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. 
>        [4]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
>        [5]accessibility at collab.sakaiproject.org
>        [6]http://collab.sakaiproject.org/mailman/listinfo/accessibility
> 
>        TO UNSUBSCRIBE: send email to
>        [7]accessibility-unsubscribe at collab.sakaiproject.org with a subject of
>        "unsubscribe"
> 
>    . . . . . . . . . . .  .  .   .    .      .         .              .    
>                    .
>    Eli Cochran
>    user interaction developer
>    ETS, UC Berkeley
> 
> References
> 
>    Visible links
>    1. http://markitup.jaysalvat.com/home/
>    2. mailto:petri.1 at osu.edu
>    3. mailto:eli at media.berkeley.edu
>    4. http://ckeditor.com/blog/CKEditor_3.2_released
>    5. mailto:accessibility at collab.sakaiproject.org
>    6. http://collab.sakaiproject.org/mailman/listinfo/accessibility
>    7. mailto:accessibility-unsubscribe at collab.sakaiproject.org

> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"


-- 
D. Stuart Freeman
Georgia Institute of Technology
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100309/addf91d3/attachment.bin 


More information about the sakai-dev mailing list