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

[Richwine, Brian L]

John,

A developer or designer using accessibility tools such as screen-readers on their own is not quite the same as working directly with a person who natively relies on their tools and who has an understanding of what the optimal experience should be.

True screen readers (like JAWS, WindowEyes, NVDA, etc.) are very complex and there is a long learning curve before one can achieve even a normal level of proficiency. Screen-readers take over the standard user interface and require the understanding of multiple operating modes and the knowledge of literally hundreds of screen-reader specific keystrokes. Without a mastery of the adaptive tool, experience gained using the tool in all day-to-day tasks, and some knowledge of accessibility issues, it would be difficult for one to correctly interpret the experience received using an adaptive tool. It would be likely that a particular feature/function could be mistakenly declared inaccessible or an impractical solution proposed.

That is why I would recommend finding local resources that you can leverage or take up Mary's (and the rest of the Accessibility Group) offer to help. If you are working on a campus, the best source of local disabled users or disability and accessibility resources is your campus' office of compliance or disabled student services. Most campus have people on campus whose job it is to help disabled students, faculty and staff, and are either willing to work with your directly or who can help find real users to give feedback.

That being said, there are a number of accessibility add-ons for web browsers that can be used to check for common accessibility related coding problems. I acknowledge that getting access to native users of adaptive technologies like screen-readers can be difficult and a limited resource. It is possible to run a number of screen reading products in trial-mode. In the case of JAWS, a popular screen reader, it is possible to run it for 20 minutes before having to reboot your computer for another round. Others, like NVDA are free. VoiceOver on Mac OS/X is included with the operating system. Keep in mind that adaptive technology tools like screen-reading software try their best to make even poorly coded applications and web pages accessible. As such, high-end screen-readers will accommodate poor coding practices (for instance if form controls aren't labeled appropriately screen-reading software will attempt to associate text from the page as a guess at the control's text label). Getting a favorable result from an adaptive technology does not mean that proper accessibility coding techniques have been followed.

The accessibility working group uses two protocols to evaluate accessibility. One protocol (the Firefox Accessibility Toolbars protocol), is used to verify technical accessibility (proper web coding).  In the second, an adaptive technology user uses their adaptive tool and follows a walkthrough script to verify functional accessibility. These protocols are available for viewing at:
http://confluence.sakaiproject.org/display/2ACC/Sakai+2.8+Accessibility+Evaluation+and+Testing+Protocols

Hope this helps!

-Brian



From: sakai-ui-dev-bounces at collab.sakaiproject.org [mailto:sakai-ui-dev-bounces at collab.sakaiproject.org] On Behalf Of John Norman
Sent: Wednesday, September 29, 2010 2:15 AM
To: Sakai UI Development
Subject: Re: Accessibility Issues with Sakai 3's TinyMCE editor

If I were to buy a screen reader so we could test this sort of thing (I think there may be an accessibility suite we can access), then is there a recommendation for what we should get? presumably it would be good that testing use a range of products?

John

On 27 Sep 2010, at 19:09, Richwine, Brian L 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<mailto:sakai-ui-dev at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20100929/3cdb0e46/attachment-0001.html