[WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to CK3.0.1
John Norman
john at caret.cam.ac.uk
Thu Nov 5 04:05:43 PST 2009
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"
More information about the accessibility
mailing list