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

[Michael S Elledge]

This is a very good analysis, Joe. Thank you for doing it.

Can any of these issues be addressed under Sakai's license for CKEditor?

Mike

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 <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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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"