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

[Humbert, Joseph A]

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<mailto:johumber at iupui.edu>     mstores at indiana.edu<mailto:mstores at indiana.edu>    brichwin at indiana.edu<mailto:brichwin at indiana.edu>      londerga at indiana.edu<mailto: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<mailto: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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20091104/6dbb220b/attachment-0001.html