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

[Mary Stores]

Hello,

I agree with everything Brian has said. However, I have a couple of additions.

JAWS runs in 40-minute mode instead of 20 minutes.

There is a free, open-source screen reader that has gained a lot of 
popularity in the blind community called NVDA (Nonvisual Desktop 
Assistant) that can be downloaded. A lot of the keystrokes are similar 
in NVDA to JAWS. One unique feature of NVDA is that there's an audible 
mouse that people with some vision can use to better select things. 
Both JAWS and WindowEyes are still more popular than NVDA, and I am not 
currently aware of any other screen reader that has the audible mouse 
feature. I personally wouldn't have enough vision to be able to try it 
if it did exist in other screen readers. I am only bringing this up to 
emphasize how different it is to use a screen reader if you aren't 
accustomed to it. Imagine...no mouse or monitor.

Mary

Quoting "Richwine, Brian L" <brichwin at indiana.edu>:

> 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
>
>