[WG: Accessibility] [Management] 2.7.0: FckEditor upgradeto CK3.0.1
Rich Caloggero
rjc at MIT.EDU
Thu Nov 5 10:37:16 PST 2009
I've done a bit of work reviewing sakai for accessibility a few years back.
I'm a long-time screen reader user.
I'd concur with the advice to offer a text-based way of composing content
like markdown or wiki markup. I think markdown syntax is easier to learn and
use.
The issues with the gui-based editors like fck and tinyMCE is that
navigation is tedious and selecting text to operate on and preserving that
selection while trying to find the right toolbar/button/link to click to
actually perform the desired operation can be frustrating and error prone.
Generally the toolbar contains many many controls, and finding the one you
want can require lots of tabbing. Since shortcut keys are not easily
discoverable, it may take a lot of tabbing in order to find the right
control even if it does have a shortcut key associated with it.
I think gui editors will be usable at some point, but slowly evolving screen
reader technology and the need for better use of ARIA markup in the widgits
themselves will make this a long road.
See the following for more on the ARIA spec (ARIA = accessible rich internet
applications):
WAI-ARIA FAQ
http://www.w3.org/WAI/aria/faq
----- Original Message -----
From: "John Norman" <john at caret.cam.ac.uk>
To: "Sakai Accessibility WG" <accessibility at collab.sakaiproject.org>;
"fluid-work List" <fluid-work at fluidproject.org>
Cc: <management at collab.sakaiproject.org>
Sent: Thursday, November 05, 2009 7:05 AM
Subject: Re: [WG: Accessibility] [Management] 2.7.0: FckEditor upgradeto
CK3.0.1
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"
_______________________________________________
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