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 menuWhen 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 ButtonThe 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.
DashboardsThe 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.
OverallWe 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.
