[sakai2-tcc] VOTE: Functionality Changes for 2.9: CKEditor

[Richwine, Brian L]

I'm obviously not on the TCC, but picked up on the CKEditor vote and want to provide some feedback in my role as QA Lead for Accessibility. 

The FCKEditor is both a crosscutting concern and the most severe obstacle to accessibility we have in Sakai CLE. 

Public universities across America are being reminded by communications from the Department of Education (DOE) and through accessibility complaints in the form of lawsuits brought by the National Federation for the Blind that they are required under Title II of the Americans with Disabilities Act and Section 504 of the Rehabilitation Act of 1973 to provide individuals with disabilities equal access to their programs, services, activities, etc. unless it would require undue burden or fundamentally alter the nature of their programs. The recent "Dear Colleague Letter" sent to institutions from the DOE [1] and the more elaborative DOE FAQ on the Dear Colleague Letter [2] make it clear that universities need to make their IT accessible in a way that is both equally available and equally easy to use by those with disabilities. 

The NFB is traveling across the country and speaking to universities letting them know if they purchase IT that is inaccessible they will be sued. For instance, they have made clear their intent to sue certain public universities if they purchase Google Apps for Education before Google makes them accessible. The NFB and ADA advocates are going as far as encouraging universities to put language in their purchasing contracts that require suppliers to verify that their products are accessible and even to indemnify the university against any accessibility complaint lawsuits that may arise due to use of their product. 

Given that seemingly comparable LMS products exist that have been certified as "accessible", universities may have a hard time justifying choosing a product with known critical accessibility issues such as dependance on the FCKEditor.

I realize that the CKEditor support in Sakai CLE could be considered immature and that there are bound to be many bugs left in the implementation. However, in today's Sakai CLE Release Management call, I heard from Sam Ottenhoff that Pepperdine University is using the CKEditor in their implementation of Sakai 2.8, that it is going well, and it sounds as if they have fixed many of the issues listed in J-F's -1 vote (the word counts for messages MSGCNTR-425, etc.). 

Unfortunately, tools and use cases that depend on the FCKEditor cannot be rated as meeting even the most basic of accessibility rating. Pushing off the CKEditor till the 2.10 release most likely would mean not being able to achieve accessibility certification for the Sakai CLE until March of 2013 given the typical release cycle. Not having tested refactoring of the rich text editor bindings to allow switching the editor will mean extended reliance on the no longer supported FCKEditor and forced dependence on IE Compatibility modes.

As implemented in Sakai, the FCKEditor's accessibility challenges include being a keyboard focus trap for keyboard only users, the FCKEditor toolbar can't be navigated by keyboard only users and is inaccessible to screen-reader users (including style, font, and color combo boxes), the form controls presented in the dialog boxes are unlabeled and in many cases the screen-reader guesses the wrong text to associate as a control's label, and paste from MS Word isn't well supported.

Given that, it does appear that may still be considerable work required to make switching to the CKEditor as clean as possible. I'm not sure of the complete status of the following:
* Refactoring of the bindings to the rich text editor across the Tools and UI Toolkit integrations including refactoring of UI cosmetics such as iFrame sizing to consistently eliminate appearance of multiple vertical scroll bars regardless of chosen editor.
* Identification and preservation or development of work arounds for rich/deep feature integrations that exist in the current FCKEditor implementation (such as the Citations Helper, etc.)
* Extensive QA Testing
* Required documentation updates

Unfortunately, I am not in a position to (or have the chops to) take on much of this work. I am sure the Accessibility Working Group would be willing to assist with the CKEditor QA testing and required documentation updates.  Again I am comforted somewhat by the knowledge that Pepperdine is using CKEditor in production. Perhaps a conference with Noah Botimer and Sam Ottenhoff would bring the effort required (and true risk) to switch to CKEditor to light.

Sincerely,
  Brian Richwine

[1] DOE June 29, 2010 Dear Colleague Letter on the Kindle: http://www.ada.gov/kindle_ltr_eddoj.htm
[2] FAQ on the June 29, 2010 Dear Colleague Letter (PDF): http://www2.ed.gov/about/offices/list/ocr/docs/dcl-ebook-faq-201105.pdf