[WG: Accessibility] [Management] 2.7.0: FckEditor upgradeto CK3.0.1
Eli Cochran
eli at media.berkeley.edu
Thu Nov 5 10:51:51 PST 2009
Rich,
Thanks so much for that perspective. This is a really important point.
We think that by adding accessible rich text editors that we're
improving the user experience for everyone, but it seems that the
accessible rich-text editors maybe a step backwards from text-based
markup. Text-based markup still has a place and should probably be
included as an option.
- Eli
On Nov 5, 2009, at 10:37 AM, Rich Caloggero wrote:
> 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"
>
> _______________________________________________
> 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
More information about the accessibility
mailing list