[WG: Accessibility] FW: Accessibility Issues with Sakai 3's TinyMCE editor

[Richwine, Brian L]

Mary Stores and I sent this email out to the Sakai UI Development list. I forgot to include the accessibility list on the email. I'll forward any replies we get back to this list.

-Brian

From: sakai-ui-dev-bounces at collab.sakaiproject.org [mailto:sakai-ui-dev-bounces at collab.sakaiproject.org] On Behalf Of Richwine, Brian L
Sent: Monday, September 27, 2010 2:09 PM
To: Sakai UI Development
Subject: Accessibility Issues with Sakai 3's TinyMCE editor

Hello,

While working on SAKIII-472, Mary Stores and I spent some time working with the TinyMCE editor in Sakai 3. Unfortunately, we found several significant accessibility issues with it and are pondering ideas on how best to proceed. Some of the issues (minor ones) appear to be with the TinyMCE editor itself. Others, including some of the more significant accessibility issues, appear to be in how the editor is being implemented in Sakai 3.

We could simply enter JIRA tickets covering the issues we found, but we doubt that would be the best way to get some of the more significant issues fixed.

The bugs in the "keyboard only" user interactions appear easy enough to explain. But, unfortunately, there are significant UI bugs that result from interactions when an adaptive technology's navigation tools are used for navigating a page. For instance, screen-reading software provides page navigation aids that assemble lists of like elements from the page into a dialog box. The screen-reader user can select an element from the list and either activate or switch focus to that element. The screen-reader user's ability to use the screen-reading software to set focus directly on an element programmatically often violates assumptions UI developers make about the possible sequences of UI event firings they need to allow for. It is hard to scratch another's itch, and a developer without access to a screen-reader user would be at a great disadvantage by not being able to explore the issues and test fixes.

Mary and I feel it would be best if the developer(s) working on these issues could work with a native screen-reader user to gain firsthand knowledge and understanding of the issues. If a screen-reader user is not available for the developer(s) to work with,  Mary and I are happy to explore  setting up a workstation where Mary can share her desktop and screen-reader audio remotely over the internet. This would allow the developer to see and explore the issues and see the results of any fixes.

For your information, here is a brief list of some of the issues we encountered. Our purpose Friday was not to perform complete accessibility review of the page editor, so this is not meant to be a complete list or a list with enough detail to work off of. The issues we encountered are:

*         In Mozilla Firefox 3.6 on windows XP and windows 7, pressing either Tab or Shift+Tab while in the Page Title Edit box changes focus to the body of the editor, effectively blocking reverse navigation up the page from the main body of the editor for keyboard only users.

*         In IE 8, pressing Tab or Shift Tab in the main body edit box inserts spaces in the document instead of moving from the main body edit box. This creates a keyboard navigation trap unless the user knows the access keys. Since the element path feature has been removed, even with the access keys, a keyboard only user can't easily get to the save/don't save buttons. (They would have to use access key Q, and then Shift+Tab all the way up through all the page controls and the Web browser's controls till they wrapped around to the bottom of the page.)

*         User interaction model for the Insert More "Combo box" is significantly different from the Paragraph, Font Family, and Font Size combo boxes.

*         Keyboard and Screen-reader specific user interactions can cause the Insert More DHTML popup to remain visible, even though user has navigated to other parts of the page.

*         The Page Title and main editor edit boxes are not labeled.

*         After using the JAWS Forms List dialog box to navigate to the body edit box using JAWS with Mozilla Firefox, the user ended up editing the Page Title instead.

*         When using the JAWS screen-reading software's Form List dialog box, It appears the only way to navigate to the body edit box is to use the forms list to navigate to the page title edit box and then use tab to move focus to the body in order to begin editing the page contents.

*         Link text for Access Keys Q and Z that are used for Jumping to the Editor's Toolbar or the Body of the editor are not coded appropriately and will appear as empty links to some adaptive technology users. The title text provided in the attributes is the same for the two links.

*         Text description provided in the title attributes of the links with Access keys Q and Z provides a browser specific description of key strokes for activating the access keys (i.e., that description is not valid for Firefox or OS/X Web browsers) - This would be fixed automatically if the links with the access keys were coded appropriately because screen readers automatically announce the correct keys to press to activate a particular shortcut.

*         Text description of Access keys refers to an Access Key X  for jumping to an "Element Path" feature that appears to have been removed in the implementation.


Mary Stores and Brian Richwine
Sakai Accessibility Working Group
UITS Adaptive Technology and Accessibility Centers
Indiana University - Bloomington/Indianapolis
http://iuadapts.indiana.edu
(812) 856-4112


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20100927/fe2b9787/attachment.html