[WG: Accessibility] Results of accessibility testing at Miami University (RE Accessibility Vol 23, Issue 2)

[Richwine, Brian L]

Thanks so much, Amy, for sharing those accessibility testing experiences! This kind of feedback is very helpful to us. I look forward to reading it more deeply.

A few questions:

   Did you make or use any walkthrough scripts when performing your testing? If so, would you be willing to share them with the Accessibility Working Group?
> Testing should determine if additional styling on multiple choice radio buttons is needed for easier readability.

   Can you elaborate on the context and the difficulties the user had? I don’t want to lose this opportunity for improvement, but don’t understand the issue you raised well enough to move forward.

   You mention the need for end user help documents. Did the user look for accessibility information and not find it? Should it be made more obvious (like a hidden link just for screen-reader users to the accessibility help information)? Besides the layout description suggestion, is there something missing from the Accessibility Information in the help system that the user could have benefitted from?

> Overall Niihka layout description was helpful for our JAWS user and helped orient her to the actions expected by the system. Online webcasts (with focus on audio descriptions) could provide this orientation in a just-in-time, on-demand way.

   I think I understand the spirit of this suggestion. Would you be willing to provide an example layout description for a tool, or to review descriptions if we create any?


I can try to answer a couple of your questions:

> Although it should be tested with colorblind simulation software,

  There are many types of colorblindness which makes it a complicated topic and difficult to check against every type of colorblindness by using a colorblindness simulator. What really counts is the contrast between the text color and the color of the text background. There are many free automated color contrast ratio checkers that work as browser plug-ins. Two plug-ins for Mozilla Firefox that we like include great color contrast checkers in them:

·         The Firefox Accessibility Extension at: http://firefox.cita.uiuc.edu/

·         Juicy Studio Accessibility Toolbar at: https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/
The WCAG 2.0 Success Criterion 1.4.3 suggests a color contrast ratio of at least 4.5:1 for normal sized text. See the Understanding WCAG SC 1.4.3 document for a great explanation of the significance of the color contrast ratio measurement and of why the 4.5:1 minimum was chosen:  http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html

> In course sites with many tools added, proceeding through the left menu could be a lengthy process. We suspect there might be a JAWS command that will skip the menu, but that may need to be researched.

  The Sakai interface has headings at the beginning of every section – this includes before each section of navigation and of course, the selected tool’s title is a heading. In JAWS, a user can press H to move forward to the next heading and Shift+H to move backwards to the previous heading. This is the easiest way to move about the page, and a standard JAWS feature. Sakai has also included three hidden links (“jump to content”, “Jump to Tools List”, and “Jump to worksite list”). These links are at the very top of every page and include an accesskey that allows quick access to those three areas. To skip past all of the content and jump right to the start of the chosen tool’s content, simply use accesskey ‘c’. This would be “Alt+Shift+C”.

Sakai follows the UK e-commerce standards for assigning accesskeys to various buttons and links in the interface. The “JAWS command ‘Alt+Shift+S’ would save or submit a form.” is actually one of the access keys put in by Sakai developers. A full list of the global and standard tool-specific access keys can be found on the “Accessibility Information” page in Sakai’s Help System (https://oncoursehelp.iu.edu/helptool/doc/arkn#keys).
> Research is needed to see if any of the screen readers could be configured to do this on an optional basis.

   There are JAWS verbosity settings, but unfortunately JAWS treats link/button text and titles as an either/or feature. It can be configured to read either the link/button text, or the title, but not both. Another popular screen-reader, GW Micro’s Window-Eyes, can be configured to read both the link/button text and the title. We have included how to configure Window-Eyes to do this in the Accessibility Information found in Sakai’s help system.

Thanks again for providing this feedback. We really appreciate it!
  -Brian Richwine


Brian Richwine
Adaptive Technology Support Specialist
Adaptive Technology and Accessibility Centers
Indiana University - Bloomington/Indianapolis
http://iuadapts.indiana.edu
(812) 856-4112




From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Amy Greenbaum
Sent: Thursday, March 03, 2011 4:49 PM
To: accessibility at collab.sakaiproject.org
Subject: [WG: Accessibility] Results of accessibility testing at Miami University (RE Accessibility Vol 23, Issue 2)

Hi everyone.  I am writing regarding to the emails from Clay and Brian in Vol 23, Issue 2

Here at  Miami University (in beautiful Oxford, Ohio) we recently tested our pilot Sakai 2.7.X instance with JAWS and Kurzweil Reader.  The JAWS testing was performed by a faculty member who uses JAWS on a daily basis and relies on it for computer access and done with members of the IT team and a representative from Longsight.  Here are some specific notes from our testing.
During JAWS testing, we noted the following:

●     General Experience
○     Overall, navigation through Niihka was good, and JAWS and Kurzweil were able to read/page through the Niihka screens in the right order, starting with site tabs, then progressing to tool links, and finally main page content.
○     Both JAWS and Kurzweil were able to handle the Niihka skin developed by Longsight from the design provided by University Communications. Although it should be tested with colorblind simulation software, on the whole the team felt the design should not present any problems for colorblnd users, with one minor recommended change below.
○     In course sites with many tools added, proceeding through the left menu could be a lengthy process. We suspect there might be a JAWS command that will skip the menu, but that may need to be researched.
○     We found that the JAWS command ‘Alt+Shift+S’ would save or submit a form. This can be a helpful tip for JAWS users because it can allow them to proceed to the next page in Niihka without having to iterate over every piece of text or link.
○     The left-hand tool menu has tool tips that describe the linked tools, which is useful for a variety of disabled users.
●     Site Info tool (Control Panel)
○     A JAWS user could successfully navigate to the Site Info tool and add and remove site tools.
●     The Forums tool
○     JAWS was able to read the student’s post and did allow the instructor to reply, but the threaded, hierarchical nature of the thread was not effectively communicated.
○     JAWS did not read how many messages were unread, which may be helpful information for Instructors.
●     Assignments2
○     Overall the experience here was good, links were easy to understand, but JAWS users may need some guidance as to the general layout.
●     Gradebook2
○     Due to Gradebook2’s advanced layout, navigating through the fields was especially challenging, and JAWS users could not consistently move from one side of the Gradebook to the other.
○     Many of the links which are selectable for mouse users could not be selected when using JAWS.
○     Although we could navigate to the student fields in the Gradebook, JAWS did not read the student names (instead it called them all 'unlabeled zero button') and we were not able to read or enter grades for individual students.
●     Rich text editor
○     Although we were able to get in and out of the rich-text editor box and JAWS was able to read student responses in the rich-text editor box, doing so was slightly challenging and unintuitive.
○     Cntrl+Down arrow gets out of the box, then the user can tab into next box.

Recommendations

Overall, we advise a combination of styling tweaks, end-user help documents, community recommendations and continued testing.

We found unstyled blue text on grey buttons (example: 'Begin Assessment' button) hard to read on the Kurzweil test machine. A more high-contrast button would be easier to read. (We will be changing this to black text on beige.)

Kurzweil 1000 and 3000 have different user experiences, both should be tested.

Overall Niihka layout description was helpful for our JAWS user and helped orient her to the actions expected by the system. Online webcasts (with focus on audio descriptions) could provide this orientation in a just-in-time, on-demand way.

Testing should determine if additional styling on multiple choice radio buttons is needed for easier readability.

JAWS doesn't read the tool menu tool tips. Research is needed to see if any of the screen readers could be configured to do this on an optional basis.

Research is needed to see if the rich-text editor box could be disabled for those using screen-readers. Alternatively, a preference setting could be created where a user could indicate that they always wanted the rich-text editor disabled.

Another avenue of investigation is editor alternatives, Niihka uses the default Sakai rich-text editor, FCKEditor. This could be swapped out for the TinyMCE editor, which is reputed to have better accessibility support. In the next version of Sakai, the updated CKEditor is also an option. TinyMCE and CKEditor should be evaluated to see if they are preferred to the default (FCKEditor).

Miami University has already engaged the Sakai Community Accessibility list, a valuable resource for current accessibility solutions and future plans for accessibility support in Sakai.

Due to the difficultly of using Gradebook2, we recommend that the original Gradebook tool be investigated as a case-by-case solution for those instructors using JAWS or other screen readers. Although Gradebook does not have all the features of Gradeboook2, it’s simpler layout will be much more navigable.

Please let me know if you have any questions,
Thank you,
Amy
______________________________
Amy Greenbaum
HR Technology & Communication Analyst
Department of Human Resources
Miami University
Roudebush Hall, 15
Oxford, OH 45056
greenbal at muohio.edu<mailto:greenbal at muohio.edu> or greenbaum.a at gmail.com<mailto:greenbaum.a at gmail.com>
o: (513) 529-4925
f: (513) 529-4223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20110304/261eb3ab/attachment-0001.html