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
[email protected] [email protected]
[email protected] [email protected]
Office 317-274-4378 Office 812-856-2760 Office
812-856-2757 Office 812-856-2763
From: [email protected]
[mailto:[email protected]] On Behalf Of
Ken Petri
Sent: Wednesday, November 04, 2009 12:32 AM
To: Eli Cochran
Cc: [email protected]; 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 <[email protected]>
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
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/accessibility
TO UNSUBSCRIBE: send email to accessibility-
[email protected]
with a subject of "unsubscribe"
