The staff at Denver DataMan have identified CiviCRM as the CRM that we believe is best suited for making a truly robust CRM that will be accessible for the blind. We have received funding from the Colorado Center for the Blind to allow us to support the development of this innovative project.
The solutions that we are proposing to implement will also help make the overall structure of CiviCRM more adaptable and in doing so paves the way for the development of mobile sites and other applications requiring functional changes based on user selections or device limitations with CiviCRM.
You can read the post I made recently on the boards to see the methodology we used to identify the issues that need to be addressed to achieve the goal of making CiviCRM accessible to the blind.
There are a few overarching areas that challenge the accessibility of CiviCRM. These are outlined here along with the proposed solution.
There are many fields in CiviCRM that do not have labels added to them and other fields that do not have clear labels defined. All of the labeling issues need to be found and fixed.
Further, a standard needs to be presented and adapted by the community to make sure CiviCRM continues creating a user interface with text cues for the blind and visual cues for those able to see the screen.
For example, the add buttons for adding more phone numbers, emails, URLs , etc. need to be labeled so that it is “add an additional email.”
This is a great place where people in the CiviCRM community can help us. If you are aware of ambiguous strings or fields missing labels please post them here or submit a patch in the issue queue so that it can be resolved. Patches and suggestions are appreciated.
The remaining issues are areas where it is necessary to show different options depending on the specifics of the users. There are many ways to address a problem like this. We are considering two of them, and possibly a combination, but the most important thing is creating a coherent plan and executing it consistently across CiviCRM.
The first way is to identify the software being used and then make changes based on the browser. This will be helpful for mobile users but since JAWS and Windows Eyes (common screen reading software) use the same browsers as sited users there is no change to the browser headers making this solution beneficial to more users but much harder to implement.
The preferred, but less flexible option is to create a system where users are assigned roles. Settings that change accessibility could be split out by various roles. An example of this being used for accessibility is allowing users with specific roles to have a specific WYSIWYG.
This same functionality is advantageous for allowing advanced users to have a text box and other users to have a WYSIWYG interface. Adding a roles system for interface management and access will add great flexibility to CiviCRM. We also see this being able to be connected with the Drupal Rules Integration MIH project.
Creating a role system is going to take some significant planning and architectural thought. We welcome the ideas and comments of the community as we embark on this project. We also want to make sure that even though we are Drupal users that our solution makes sense in the Joomla and Wordpress environments as best as we can.
This project is a large undertaking and one that we hope the community will grab onto. There are opportunities to make these changes in ways that will not only be a benefit to those who are blind but also to those trying to further customize how CiviCRM works.