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

Amy Greenbaum greenbaum.a at gmail.com
Thu Mar 3 13:48:50 PST 2011


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 or 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/20110303/8df1c26d/attachment.html 


More information about the accessibility mailing list