[WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to CK 3.0.1

Mon Nov 2 13:20:20 PST 2009

Mike,
Has anyone in the accessibility community evaluated the new CKEditor  
to determine if it really does deliver on the promise of being more  
accessible?

- Eli

On Nov 2, 2009, at 7:00 AM, Mike Elledge wrote:

> Hi Everyone--
>
> FCKeditor has been a such a critical accessibility issue for sooooo  
> lonnnnggggg that it would be a huge win for Sakai if you could  
> update to a more accessible version. I realize that it touches many  
> areas of Sakai, so it isn't a trivial change. Nonetheless, it would  
> be very welcome.
>
> Thanks!
>
> Mike
>
> Clay Fenlason wrote:
>> At first glance I would say the real issue here is the maintenance
>> one: what the scope of QA would be, given the ubiquity of the editor.
>> It's not entirely comforting to think of this as a drive-by drop in
>> from Josh without a commitment to fix issues that may surface during
>> QA (if I'm reading the email thread right), but again that seems to  
>> me
>> the sort of call that a combination of technical review and QA
>> leadership should resolve in community discussion.  Maybe even - dare
>> I say it - a good issue for a maintenance team to weigh in on.
>>
>> That said, if I look at what CKEditor 3.0 is all about, I find the  
>> following:
>>
>> http://ckeditor.com/blog/CKEditor_3.0_is_here
>>
>> ... which includes "Brand New UI" and "New Javascript API." I still
>> think a maintenance/QA review should take the lead on these kinds of
>> questions, not the product council as a general rule, but CKEditor  
>> 3.0
>> is clearly more than just a bugfix release, and should be discussed
>> on-list before inclusion.
>>
>> ~Clay
>>
>> On Sun, Nov 1, 2009 at 3:10 PM, Anthony Whyte <arwhyte at umich.edu>  
>> wrote:
>>
>>> Councillors--Josh Ryan suggests that we consider for 2.7.0  
>>> upgrading the
>>> FckEditor (currently 2.6.4) to the renamed CK 3.0.1.  I replied to  
>>> him that
>>> such an upgrade (considering it's wide-ranging impact across the  
>>> tool set)
>>> might require consideration by the Product Council.  "Might" is the
>>> operative word here since it is unclear to me at present if such  
>>> an upgrade
>>> requires Product Council approval given that it may well fall into  
>>> the
>>> "maintenance" category.  Your views on this question would be  
>>> appreciated.
>>> Cheers,
>>> Anth
>>> Begin forwarded message:
>>>
>>> From: Noah Botimer <botimer at umich.edu>
>>> Date: October 30, 2009 12:56:14 PM EDT
>>> To: Anthony Whyte <arwhyte at umich.edu>
>>> Cc: Joshua Ryan <josh at asu.edu>, Clay Fenlason <clay.fenlason at et.gatech.edu 
>>> >
>>> Subject: Re: 2.7.0 textarea (new feature freeze 12 Nov 2009)
>>> I think this is worth serious investigation. Although it is new  
>>> code from
>>> them, we're talking about a Sakai release with a long lifetime.  
>>> Their 2.6
>>> branch has been stagnant for quite a while and they've been  
>>> addressing many
>>> issues in the new line (notably accessibility and abysmal  
>>> performance).
>>>
>>> I don't know how I would classify it in relation to the new  
>>> process. R&D?
>>> Incubation? Product Development? Maintenance?
>>>
>>> Since there is already the pluggable editor functionality, it may  
>>> even be
>>> possible to include it as an option (maybe the default), rather  
>>> than a
>>> replacement. That might free us up for some process options.
>>>
>>> Thanks,
>>> -Noah
>>>
>>> On Oct 30, 2009, at 12:09 PM, Anthony Whyte wrote:
>>>
>>> CK 3 sounds good but we've got a new development process overseen  
>>> by the
>>> Product Council and I imagine they might need to approve such a  
>>> change.  I'm
>>> cc'ing Clay and Noah (who has a long interest in FCK) for their  
>>> thoughts.
>>>
>>> Cheers,
>>>
>>> Anth
>>>
>>>
>>> On Oct 30, 2009, at 11:58 AM, Joshua Ryan wrote:
>>>
>>> Hey Anthony,
>>>
>>> . . . I don't really foresee having time to do much for 2.7.0,
>>>
>>> however the latest version of the FCKeditor (3.01, now called
>>>
>>> CKeditor) is pretty damn nice. It's substantially faster and it's
>>>
>>> finally fully accessible! So if I can scrap together some time that
>>>
>>> could be a very nice change but I really can't promise anything  
>>> and I
>>>
>>> wouldn't want to hold things up at all. How about I try to sneak  
>>> it in
>>>
>>> this weekend and if I don't get most of the way done by Monday then
>>>
>>> just pretend I didn't mention it and branch when ever you want.
>>>
>>> /Josh
>>>
>>> On Fri, Oct 30, 2009 at 7:54 AM, Anthony Whyte <arwhyte at umich.edu>  
>>> wrote:
>>>
>>> Josh--I may well be taking on Pete Peterson's Foundation QA  
>>> oversight role
>>>
>>> on an interim basis through the release of 2.7.0 in my capacity as  
>>> release
>>>
>>> manager.  As a first step I would like to propose that we impose a  
>>> feature
>>>
>>> freeze on core trunk code intended for 2.7.0 earlier than Pete's  
>>> original
>>>
>>> proposal included below.  If I could, I'd say let's freeze  
>>> tomorrow and I'll
>>>
>>> create the 2.7.x branch.  But instead I'd like to impose a feature  
>>> freeze on
>>>
>>> Thursday, 12 November 2009, 8:00 pm EST and then create the 2.7.x
>>>
>>> immediately thereafter.  That is two weeks from now.
>>>
>>> Projects on an independent release track will not be affected by  
>>> this date
>>>
>>> (e.g., msgcntr) although we need those teams to start putting out  
>>> stable
>>>
>>> releases (binding to snapshot versions is not acceptable in a  
>>> release).  A
>>>
>>> freeze on message bundles can occur later.  Bug fixes can of  
>>> course continue
>>>
>>> to flow from trunk into 2.7.x unhindered until we decide on a  
>>> release
>>>
>>> candidate date, when bugs will be triaged thereafter (e.g.,  
>>> blockers,
>>>
>>> critical fixes get priority).
>>>
>>> So for textarea would such a date work for you?  If not can you  
>>> summarize
>>>
>>> for me new features that you intend to add that make this date  
>>> problematic
>>>
>>> for you.
>>>
>>> Cheers,
>>>
>>> Anthony
>>>
>>>
>>> _______________________________________________
>>> 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"
>>>
>>>
>> _______________________________________________
>> 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"
>>
>>
>>
> <melledge.vcf>_______________________________________________
> 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