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

[Richwine, Brian L]

Thanks. I'll open that JIRA for tracking.

-Brian

-----Original Message-----
From: sakai-ui-dev-bounces at collab.sakaiproject.org [mailto:sakai-ui-dev-bounces at collab.sakaiproject.org] On Behalf Of Alan Marks
Sent: Monday, September 27, 2010 5:19 PM
To: Sakai UI Development
Subject: Re: Accessibility Issues with Sakai 3's TinyMCE editor

Guys, thanks for taking a look. We appreciate the feedback. I think
you're right, adding a bunch of Jiras for each item probably isn't the
best starting point, if we have such broad issues. But maybe at least
open one as a tracking issue. Nico and I will put our heads together
on the best way to take advantage of your offers.

On Mon, Sep 27, 2010 at 11:09 AM, Richwine, Brian L
<brichwin at indiana.edu> wrote:
> 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
>
>
>
> _______________________________________________
> sakai-ui-dev mailing list
> sakai-ui-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev
>
>



-- 

Alan Marks | Sakai 3 Project Director
tele: 425-785-3284 | skype: skramnala
_______________________________________________
sakai-ui-dev mailing list
sakai-ui-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev