Sakai Accessibility Working Group Conference Minutes 11-05-2009

Attendees

Scott Williams (UMich), Mike Elledge (MSU), Eli Cochran(UC Davis), Brian Richwine (IU), Joe Humbert (IU), Margaret Londergan (IU), Mary Stores (IU).

Notes

Notes taken by Mary Stores.

Discussion continued on how to develop new accessibility testing protocols for Sakai 2.x and Sakai 3. Eli mentioned that understanding Sakai's accessibility goals is important to knowing how to proceed.

As far as developing guidelines/recommendations for developers, Eli suggested that developers would benefit best from a checklist like document so they know what actions to take in order to meet goals for accessibility design.

Brian made a request to gather materials for developing an accessibility testing protocol that would better fit a web application like Sakai 3. Mike suggested looking at the WAI-ARIA best practice document. Eli and Mike mentioned they would send protocols they know of to the list.

Discussion turned to the WYSIWYG editors TinyMCE and the CKEditor (latest version of the FCKeditor) and markdown/Wiki text-based editors. The fckEditor used in current versions of Sakai is inaccessible and there has been some recent conversation on Sakai email lists about upgrading it to its latest version (the CKEditor now at version 3.0.1), which claims to be accessible.

The ATC's Web Accessibility team did a quick investigation of the CKEditor (using the demo version found on the ckeditor.com site) with JAWS, and found that while it is an improvement over the FCKeditor, that several accessibility issues exist. While the CKEditor is somewhat usable to users with disabilities, it is only so with restricted abilities and through much annoyance. Some issues noted include:

• After activating editing features found on the tool bar, the contents of the editor window seemed to either disappear to JAWS, or become out of sync with the displayed contents. This required the JAWS user to press Insert+Z twice slowly (disabling and then enabling JAWS's virtual cursor). This was initially a source of much confusion and quickly switched to being very annoying. Besides being a source of great annoyance, it could easily lead the user to making errors in editing.
• The CKEditor's toolbar was not accessible with the standard browser navigation keys. Focus skips over the toolbar and the user is required to know the CKEditor specific hot key combination to access it.
• 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 input fields in the CKEditor's dialog boxes are not labeled
• 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.
• No keyboard accessible link is available that lists the access keys, usage hints, or any other necessary end user documentation for the editor.
  (Further rigorous investigation would be needed, in downloading the code and examining the CKEditor's developer's guide to see if installation or configuration options could improve the accessibility.)

It was noted that Mary has had better success using the WYSIWYG TinyMCE editor. (The TinyMCE editor appears to be in use on the Sakai 3 demo server.)

Both the CKEditor and the TinyMCE editors can be configured to allow the user to toggle between editing in the WYSIWYG mode and a text only mode (HTML, Wiki Markup, etc.).

It was determined that no matter which type of editor is used students will experience a learning curve because of the keystrokes needed to mark up the document. (The ATC sent their initial findings on the accessibility of CKEditor to the Accessibility WG email list on November 4.)

Near the end of the meeting, Eli proposed that the Accessibility working group develop Sakai's accessibility goals and criteria by the next regular meeting (in 2 weeks). It was suggested that the Accessibility Working Group's wiki space on confluence be used for this effort's workspace. Eli will put a document up on the space which will outline how work on developing the accessibility goals can begin.