Accessibility In CiviCRM – Analysis and a move to fix it

[denverdataman]

Trying to find a rich, web-based CRM application that works well with screen readers for the blind is challenging. My team has identified CiviCRM as being the place that we intend to place our efforts and the backing of the Colorado Center for the Blind.

We have reviewed the efforts of CiviCRM including the report commissioned in 2007 (http://wiki.civicrm.org/confluence/pages/viewpageattachments.action?pageId=6930&metadataLink=true) and looked at other posts made and work done by the CiviCRM community.

We have worked with our client using Jaws for Windows  (http://www.freedomscientific.com/products/fs/jaws-product-page.asp) to identify key issues with the way that CiviCRM currently operates and try and find ways to make it work more effectively for users with screen readers while not diminishing from the user experience for those without visual impairment.

Our research on the problems that need to be addressed were tested in Internet Explorer 7 using JAWS for Windows.  An instructor at the Colorado Center for the Blind helped us do our examination.

Navigation menu

When looking at the Navigation menu it was not possible to move from Home to Contacts but rather the navigation moves from Home to Logout. The same behavior can be seen when tabbing between items in Firefox.

When trying to use Quick search on the Navigation menu it does not appear to work.

Create New Button
The Create New button and other buttons like it do not work with the screen reader. The problem appears to be that it is not a button in a way that a browser can see it as such. For issues like these replacing (based on a role or other setting for specific users) these buttons with another type of dropdown may work well.

Help Buttons
The help buttons do not work for screen readers. I believe this is because they are placed with java script. It might be possible to put in different buttons if the user has a specific role or other designation. 

Contacts   
Collapsed field groups cannot be tabbed to and cannot be voiced by JAWS. They do not work if you try to tab to them either.

When adding a name the possible duplicates list is very hard to use with JAWS. It would be great to add something like a There are X possible duplicates and then a skip duplicates button. This would allow users to know how many items there are to review or to skip if they do not believe there to be duplicates. This is a better fix than simply turning off this feature.

The dropdown for the Current Employer does not work. Though it’s possible to scroll through the options with the up and down keys these were not voiced by JAWS.

The add buttons for adding more phone numbers, emails, URLs , etc. need to be labeled so that it is “add an additional email” etc.

On Hold and Bulk Mailing are not labeled.

The Signature field cannot be tabbed to.

There are not labels on any of the email, phone, fields, etc.

Clear links for example on Most Important Issue field are not labeled.

Calendar buttons do not work. The code blocks any input with the keyboard however if available this would work just fine. 

The Create New Contact box linked from Select Contact box tells the user that it is adding a new contact but none of the fields are labeled.

The word addt’l address should be spelled out as additional as this does not make sense.

The zip +4 box does not have a label.

When you use the additional address function in the address box it reloads the entire page.  This means that the user has to tab through the entire page again.

Dashboards
The dashboards system does not work.  Finding a way to make dashboards powerful and dynamic while not only using visual cues is going to be challenging but I believe it is something that can be accomplished.

Other places on the site like the ability to change orders of parts of the contact add form only use visual cues. These should degraded to show a weight option of some sort like in Drupal. This would show a nice mouse driven GUI to those users able to use it and a usable tool for those not able to use their mouse. 

WYSIWYG
WYSWYG editing is always challenging but forms need to be able to turn off WYSIWYG editing and allow for HTML. Something like the Drupal WYSIWYG module that turns on or off for specific user roles.

Overall
We have simplified our findings here; buttons that do not work in one place do not work in other places as well.   For example all calendars do not work.

All of these issues and others that will be found appear to be resolvable. Denver DataMan and our partners with the support of our client are looking to solve these problems. Before we work to make these changes we want to share our findings with the community.

If the community has thoughts on how they would like to see this work done we want to hear. If there are related issues we want to know about that as well.

[Michał Mach]

Steve,

Thanks for the detailed analysis - it seems to me like a very valuable material. Would you like to make it more visible to the community and publish it as a blog post on civicrm.org? I think that would encourage others interested in this discussion to join the conversation and maybe also the effort to fix identified problems.

Thx,
m

[xavier]

Hi,

Impressive work, thanks.

Some of the issues (calendar, navigation, autocomplete, and possibly field groups) are existing plugins we use, and are used by a lot of different softwares. It would be very useful for the community at large that you share these results or the fixes you find with them, so not only civi but the other using these libraries get more accessible to.

X+

[Kurund Jalmi]

Thanks for the feedback. Looks like few issues might be related to your install. So would be great to verify few things on http://drupal.demo.civicrm.org

Kurund

[Donald Lobo]

Hey steve:

thanx for the report. a few thoughts and comments:

1. Would be great if you can publish the full report so folks can take a closer look. As michal suggested, blogging about this on civicrm.org will help a wider audience understand why this is important and some tradeoffs involved. Let us know and we can enable blogging privileges for u on civicrm.org

2. Based on our past experience and your current summary, i would classify the issues into three areas:

* Easy (a lot of the missing label and spelled out words): We can work with your developer(s) and get all of these things fixed for the 3.4 release

* Medium: Tabbing issues, Calendar widget etc. I suspect most of these can be tweaked to meet your needs. Depending on the resources available, we might be able to tackle a fair number of these for the next release.

* Hard: Things where we need have alternative based on role/setting etc. Its not hard per se, but just requires more code and some thoughts on how to structure it. This is the biggest commitment in terms of time and resources and might be worth tackling it in a coherent manner across the platform

Would be great to see CiviCRM move towards being more accessible. Thanx for stepping up and leading the project down this road

lobo

[denverdataman]

Thanks for the feedback. Looks like few issues might be related to your install. So would be great to verify few things on http://drupal.demo.civicrm.org

Kurund

Can you please share what features these are as this is a clean install of the 3.3 beta and I have seen these issues in other places. 

[denverdataman]

In response to Lobo:
1.  I would be glad to write a blog post and could get this done early next week (Monday or Tuesday).

2.

"* Easy (a lot of the missing label and spelled out words): We can work with your developer(s) and get all of these things fixed for the 3.4 release"

One of the challenges that my developers and I are having is we have not done much with themeing in Civi before and we are wondering if there is a directory of files to help better know where fields will be.

What is the timeline for the 3.4 release given that 3.3 will be soon?

"* Medium: Tabbing issues, Calendar widget etc. I suspect most of these can be tweaked to meet your needs. Depending on the resources available, we might be able to tackle a fair number of these for the next release."

That makes sense.

"* Hard: Things where we need have alternative based on role/setting etc. Its not hard per se, but just requires more code and some thoughts on how to structure it. This is the biggest commitment in terms of time and resources and might be worth tackling it in a coherent manner across the platform"

We want to do this in a way that makes sense and has community buy-in. I will flesh this out a bit more in the blog post and what I think should be done.

[Donald Lobo]

1. 3.4 release schedule is here:

http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+v3.4+and+v4.0

As always we periodically tweak those dates to reflect the latest situation

2. CiviCRM uses Smarty (http://smarty.net) to render most of the html. Some instructions here:

http://wiki.civicrm.org/confluence/display/CRMDOC33/Customizing+CiviCRM+Screens

We can also work on improving the core code as needed. You / your developers should  ping us on IRC with any specific questions

Looking forward to the blog post and the complete report

lobo

[denverdataman]

When is a good time to catchup on IRC. I have been trying to watch for you for a couple of days. I do a lot of moving between places so not the best at watching chats.

Thanks,
Steve

[Donald Lobo]

should be on more consistently from tomorrow. past few days the kids had holidays feel free to start a conversaton on irc. there are quite a few knowledgeable folks on the channel :0

lobo