[Management] [WG: Accessibility] 2.7.0: FckEditor upgrade to CK3.0.1

Noah Botimer botimer at umich.edu
Thu Nov 5 21:39:27 UTC 2009

I think this is the right question. ("Does the choice really matter  
now or is it more important that we have made a choice?") I have some  
specific thoughts about the CKSource/Moxiecode debate, but will spare  
them for now.

What I will say in my typical diffusive fashion is...

Google has released their "Closure Library" today, which includes  
their rich text editor:


It looks like everything is licensed Apache 2.0.

By the way, this also includes the "seamless editor" mode that made  
Page Creator so attractive to me. I have been waiting for this for  
two years and will definitely be researching it.


On Nov 5, 2009, at 7:05 AM, John Norman wrote:

> Excellent work, thanks.
> A particular interest of mine surounds the comparison between CK
> Editor and TinyMCE. We chose to work with TinyMCE in Sakai 3 largely
> because of its reputation for handling accessibility issues (but also
> because of its plugin support). Is there anything in this new CK
> Editor release that would suggest we need to revisit that decision,
> bearing in mind that it might require a _lot_ of work? But if the
> signs are there we should pay attention. Presumably TinyMCE will be
> continuing to develop and we may just be seeing normal technology  
> leap-
> frogging in action.
> cc'ing Fluid in case they have any insights...
> Best, John
> On 4 Nov 2009, at 19:20, Humbert, Joseph A wrote:
>> Hello,
>> The web accessibility team at the Adaptive Technology and
>> Accessibility Center has performed scenarios to test the usability
>> and accessibility of the new CK Editor using the accessibility
>> documentation found at http://docs.cksource.com/CKEditor_3.x/ 
>> Accessibility
>>  . We believe that while the CK Editor is more accessible than the
>> FCK Editor currently being used for Sakai, there are some
>> improvements that need to be made to increase the accessibility of
>> the editor and be more in conformance with WCAG 2 guidelines. Below
>> is a list of issues, along with suggestions for improvement of the
>> editor and documentation.
>> The reason the CKEditor is a step forward is because in previous
>> versions of FCK Editor, the only way for students using a screen-
>> reader to submit assignments was to upload a Word (or some other
>> file type) document. Screen-reader users could not access, for
>> example, the font options if a professor wanted the assignment in 12-
>> point Times New Roman. With the CKEditor, though, screen-reader
>> users can type or paste their assignments in the editor, adjust
>> fonts, make words bold, italic, etc.
>> Regarding the documentation about using JAWS with the editor:
>> ·         “JAWS Editing Mode vs. Non-Editing Mode” – this is
>> actually called Forms Mode.
>> ·         No mention is made, that I can find, of the version of
>> JAWS this documentation was written for. Starting in version 10 the
>> high-pitch pop sound indicates that the user can start typing text;
>> there is no need to press Enter to activate the edit mode because
>> JAWS now detects the need to do this automatically (unless the JAWS
>> user has the auto-forms mode setting turned off).
>> ·         The CKEditor’s tools list, which can be accessed by
>> pressing Alt+F10, can also be accessed with the JAWS screen reader
>> using the JAWS links list dialogue, Insert+F7. In addition, no
>> mention of the JAWS Forms List dialogue, Insert+F5, is mentioned,
>> which is the easiest way to get to the edit field where text can be
>> written.
>> We would be happy to rewrite the JAWS documentation so that JAWS-
>> specific keystrokes are mentioned for easier navigation.
>> Improvements to Enhance Accessibility of the Editor:
>> ·         All form fields should be labeled. The initial edit field
>> of the editor itself (where the user inputs text), as well as all
>> resulting form fields that the user can create in their document
>> (when, for example, selecting a radio button), are not labeled.
>> There is also no option for the user to create accessible form  
>> fields.
>> ·         The frames for the different components (the editor, the
>> spell check dialog, etc.) need better labels. For instance, when
>> JAWS users utilize the frames list dialog while spell checking,
>> titles such as “mid” and “bot” do not make sense.
>> ·         The various fields that appear in the CKEditor’s dialog
>> boxes are not labeled (ie: spell checker, defining radio buttons,
>> etc.).
>> ·         The “Drop down boxes” on the CKEditor’s toolbar are not
>> announced as dropdown boxes by a screen reader when selected. There
>> should be actual drop down boxes instead of links that use scripting
>> to emulate dropdown boxes.
>> ·         To screen reader users, all tools in the CKEditor tool bar
>> appear as links on separate lines (with blank lines between
>> groups).  These should instead appear in lists and nested lists for
>> easy navigation by screen-reader users. JAWS users can press l and i
>> to jump to lists and list items. Screen-reader users will then be
>> able to understand how many items are in each list and their
>> relation to one another, e.g., styles, format, font, font size, text
>> color and background color are all related.
>> ·         The dialog boxes for the CKEditor (like when creating a
>> radio button) appear at the bottom by the page when activated using
>> JAWS. When the tool’s link was first clicked, it appeared as if
>> nothing happened. We had to search the page to find that the dialog
>> box’s content had appeared. An anchor tag and appropriate scripting
>> should be added so when the dialog opens focus can be given to the
>> anchor tag where the dialog box’s content is located.
>> ·         The CKEditor’s toolbar isn’t easily accessible to keyboard
>> only users. When the keyboard user navigates into the editor, focus
>> immediately jumps to the content area, skipping the tool bar. The
>> normal tab/arrow key navigation cannot be used to access the
>> toolbar. It isn’t immediately obvious (because instruction to do so
>> isn’t given on the page) that the keyboard only user needs to press
>> Alt+F10 to get into the toolbar (After pressing Alt+F10, then the
>> keyboard user can arrow through the toolbar’s controls).
>> ·         A keyboard accessible link needs to be provided that lists
>> the access keys and other necessary user documentation for using the
>> editor.
>> This is only a summarization of the testing we did and the issues we
>> found. We would be happy to write a more detailed report explaining
>> the protocol we used to do the testing and the scenarios we
>> performed. We would also be very happy to discuss these issues and
>> any questions you might have at the Sakai Accessibility Working
>> Group teleconference which is tomorrow November 5, 2009 at 2 PM
>> Eastern time. The phone number is (812) 856-3600 and the PIN is
>> 002264#. All are welcome to attend.
>> Web Accessibility Team
>> UITS Adaptive Technology and Accessibility Centers
>> Joe Humbert                Mary Stores                   Brian
>> Richwine                Margaret Londergan
>> johumber at iupui.edu     mstores at indiana.edu
>> brichwin at indiana.edu      londerga at indiana.edu
>> Office 317-274-4378     Office 812-856-2760       Office
>> 812-856-2757         Office 812-856-2763
>> From: accessibility-bounces at collab.sakaiproject.org
>> [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of
>> Ken Petri
>> Sent: Wednesday, November 04, 2009 12:32 AM
>> To: Eli Cochran
>> Cc: management at collab.sakaiproject.org; Sakai Accessibility WG; Clay
>> Fenlason
>> Subject: Re: [WG: Accessibility] [Management] 2.7.0: FckEditor
>> upgrade to CK3.0.1
>> Hi Eli,
>> I think Hadi is the best one to address this. He is screen reader
>> reliant. I just use them for testing.
>> However, in my experience you gain two things from a markdown/
>> textile/wikitext form of input: 1) Since you are working with just
>> text, there are no UI complications for either screen reader or
>> keyboard-only users, and 2) End users are much more conscious of
>> what they are doing in terms of the semantics of a page and, if your
>> parser is good, you can guarantee perfect HTML output (outside of
>> HTML intentionally included by end users).
>> Hadi has worked closely with systems that take wikitext/textile
>> input for HTML rendering. He is also a very experienced developer.
>> Best,
>> ken
>> On Tue, Nov 3, 2009 at 3:05 PM, Eli Cochran <eli at media.berkeley.edu>
>> wrote:
>> Ken,
>> I'm curious about your recommendation. Is your experience that the
>> overhead and complexity of navigating rich text controls with the
>> keyboard makes it more appealing to screen reader users or keyboard
>> users to use a wiki-style markup language instead? It actually makes
>> a lot of sense to me, but I'd never really thought about it, nor
>> have I heard this before.
>> Thanks,
>> Eli
>> On Nov 3, 2009, at 10:31 AM, Ken Petri wrote:
>> Though I'm not involved in the Sakai Access WG except as a lurker
>> (and now a poster, I guess), my ultimate recommendation would be to
>> offer an option to use Textile or WikiText or Markdown or some
>> similar text based/interpreted for content editors.
>> . . . . . . . . . . .  .  .   .    .      .         .              .  
>>                     .
>> 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"
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
> TO UNSUBSCRIBE: send email to management- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

More information about the fluid-work mailing list