Accessibility

[Matt M.]

Hello,

I showed your product to some of our systems folks, and besides a lot
of excitement, there was one issue that came up that we need to
address. One of the criteria for CSU campuses is that there are like
alternatives for users if JavaScript is disabled in their browser
(http://www.calstate.edu/Accessibility/webaccessibility/evaluation/ :
checkpoint L). Have you addressed or heard anything about this yet
from others? We are going to be testing using some of the adaptive
technologies that we have available to us and discussing the issue
more in the next couple of days, but I wanted to ask you as well. We
are considering the link to our QuestionPoint chat service and the
prominent display of our telephone number as addressing this issue,
but no decisions have yet been made.

Thanks,
-Matt

[Pam Sessoms]

Hi Matt,

Great question. To answer, no, this has not yet come up from others,
but we've been wanting LibraryHelp to be accessible to those using
screen readers since the beginning. More on that in a bit.

Providing accessible web chat without javascript would be very
difficult. QuestionPoint, both the standard chat and the Qwidget,
seem to require Javascript for the chat to actually work, so I don't
think pointing to QP when javascript is disabled will solve this
issue. Displaying your phone number and/or e-mail address might.
Also, there are IM clients that work with screen readers, so if your
screen reader patrons have IM accounts and your library has an account
on their protocol (AIM, whatever), that would work in terms of a
roughly equivalent service. I know that IM is different than web chat
and does require that the patron have an account, but at least they
are both synchronous online chat services. You should be able to use
LibraryH3lp's API's to display whatever you'd like if a patron without
javascript shows up. For instance, in "the easy way" sample code on
the wiki, users without javascript will see whatever you have set to
display when your chat is offline (link to e-mail form, phone number,
whatever).

Other thoughts... Meebo Me widgets actually do not require javascript
on the patron's side, but their implementation of Flash is completely
inaccessible. I asked the Meebo folks specifically about this awhile
back, and they had no real plans at that time to specifically work on
Meebo Me's accessibility, although they did say that others were
working on making Flash more accessible in general.

Now, specifically about LibraryH3lp. As I mentioned, we want it to be
accessible to users of screen readers. I am a very poor user of Jaws,
which is the standard screen reader our campus uses. I can get Jaws
to read LibraryH3lp chat text. I have more trouble getting Jaws to
actually find the chat widget on a web page. This might have to do
with my lack of expertise with Jaws, or there might be ways we can
improve the widget's "findability" for screen readers, or it might
have been shoddy web design on my test web page that included the
widget. Please let me know how your testing goes. We've been looking
for someone with screen reader expertise to do real testing in this
area and let us know how we can improve the widget. One thing we know
we want to build in, for example, is the option for the user to have
it play a sound whenever the librarian sends a new message. That
should help users of screen readers.

Best wishes,

-Pam.

--
Pam Sessoms, Electronic Reference Services Librarian
phone 919/962-1151; fax 919/962-5537; AIM: SessomsPam
Walter Royal Davis Library, Reference Dept.
UNC-Chapel Hill, CB 3922
Chapel Hill, NC 27514-3922

[Matt M.]

Thanks very much for your response. I am still trying to get my head
wrapped around 508 and WCAG compliance and am starting to get a
clearer picture. We did some testing in Jaws and got similar results
with our limited expertise. We have also emailed someone at Disabled
Student Services to see if we could test it out with him and get some
further clarification but have not heard back yet. Hopefully we will
get some good information from this session and I will share any that
I get.

Thanks again,

Matt Mallard
Reference and Instruction
CSUF Pollak Library
mmal...@fullerton.edu

[Matt M.]

Hello Pam,

We did our testing today with Jeff Senge (http://
campusapps.fullerton.edu/news/Inside/2007/accessibility.html) from the
Information and Computer Access Program in the Office of Disabled
Student Services at CSUF. He really liked how simple the application
was and pointed out a few things:

1. The user is not able to tell when new text is entered and therefore
has to check back to see if the conversation has been updated. He said
that some sort of sound would solve this problem, just as you
suggested in your previous post.

2. On a usability note, the user has to scroll through all of the
previous conversation in the chat window to get to the new text
entered by the librarian (from the top to the bottom). One
(unintended) workaround that he discovered is that the new text is
displayed without the rest of the conversation every time the user
accesses their chat area (or edit field) when using the Insert+F5
command. But this was something he found through serendipity.

3. The "Type here to chat." message does not go away when using JAWS.
That text will remain unless deleted manually.

Again, he was really pleased with the simplicity and was excited to
see something like it. He said that adding much more in the way of
accessibility would detract from the simplicity, an idea which he
didn't seem to favor. He said that our implementation was compliant
and that an intermediate (rather than beginner or advanced) user could
use it effectively. He did note that he liked our use of alt tags and
the text that was entered in case the <iframe> didn't work. He also
showed us that the user could review the entire conversation using the
JAWS Virtual Window.

Let me know if I can answer any other questions or if I can ask more
questions of Jeff.

-Matt

On Apr 30, 7:19 am, "Pam Sessoms" <psess...@gmail.com> wrote:

[Pam Sessoms]

Hi Matt,

Thank you so much for coordinating this testing and passing along this
wonderful, detailed feedback! There is a lot of really useful
information in here. We're really pleased that he thinks it's
compliant and that at least intermediate-level Jaws folks should be
able to use it effectively.

It's good to hear verification from an expert that playing a sound
when the librarian sends a new message will help accessibility.
Eric's starting on that today and we'll try to get this feature out
soon. I'll update this thread when it's in place. The sound will be
on by default. Eric tells me the trickiest part is getting the "sound
off" option to not mess up the widget layout in IE too much.

I'm going to explore what happens with Insert+F5 to read just the new
text and also the Jaws Virtual Window further to learn more about how
this all works. We'll also see if we can improve the situation with
the manual "type here to chat" message deletion for Jaws users.

On a related note, Eric's just released a new feature in the admin
interface to help with creating web pages. It's called the
"servinator" and it generates HTML snippets for you on the fly. One
of the things it offers is automatic notification that chat requires
javascript. It lets you pick the text displayed to browsers without
javscript (default is "Chat requires JavaScript").

The servinator is also about flexible service levels -- you can
preferentially connect patrons with different queues to suit a
specific situation and you can specify exactly what to do if no
matching librarians are online. Example: If a subject expert is
online, connect to the expert; if not, connect to the general
reference desk; if ref is offline, connect to circulation; if that is
offline too, show a link to the e-mail form or the 24/7 backup service
or hide chat entirely. It's complimentary to a feature released this
weekend called "the configurator," which provides a WYSIWYG interface
for customizing widget skins.

Thanks once again for taking up the accessibility testing!

Best wishes,
-Pam.

[Pam Sessoms]

Couple of updates:

On May 7, 11:08 am, Pam Sessoms <psess...@gmail.com> wrote:
> It's good to hear verification from an expert that playing a sound
> when the librarian sends a new message will help accessibility.
> Eric's starting on that today and we'll try to get this feature out

> soon. I'll update this thread when it's in place. .

The sound alert is in place now.

Note that since this adds a new element to the widget, there might be
caching issues on machines that have previously displayed widgets
(like test machines), and a refresh and/or cache flush might be needed
to make it layout correctly.

> We'll also see if we can improve the situation with
> the manual "type here to chat" message deletion for Jaws users.

Eric believes he's fixed this now too. :)

Let us know if other accessibility issues come up.

Best,

-Pam.