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.
Labels and Clarity
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.
Tabbing and Field Usability
There are issues with tabbing and field usability. These are issues that will be harder to solve. We will need to evaluate each field and decide on the best way to resolve each field and at all times trying to keep as much of the interface intact as possible for all users. Creating JavaScript that degrades well will benefit all users. A common issue is that calendar fields do not accept text input but only accept input from using the non-accessible calendar tool.
Creating a Role Based Usability System
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.
Closing
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.
Comments
I think it's possible to make steady progress on this over time, especially if you tackle low hanging fruit first. MIght be good for you and / or Colorado Center for the Blind to reach out to other similar organizations to collaborate on sponsorship and user testing.
You mentioned JavaScript in passing, but I think it will be the biggest challenge by far.
Also with role-based interfaces I would suggest keeping this to a bare minimum. I can see how this would work great with WYSIWYG editors, but not much else. If there are multiple UIs that need to be maintained all over the place it will be a maintenance nightmare. I can tell you which UI will be the one that gets forgotten about and gets buggier and buggier as time goes by.
As you noted in your forum post, there is A LOT of work to be done to make CiviCRM truly accessible. Having done a lot of work on the templates in 3.2, I thought might give some insight on what I see as major challenges:
1) Dalin is right - you are going to have *major* javascript issues. There are a lot of pieces of the system that do not function without javascript, and as I understand it, this is not ideal. There are, I imagine, some workarounds (addressed in next section), but it would be great if you could take some time to work with Kurund et. al. to start pulling javascript out of actual html templates and putting them into their own (overrideable) files.
2) Form accessibility - I did some work on making forms more accessible in the 3.2 release (a not perfect, but possibly helpful example: http://wiki.civicrm.org/confluence/display/CRMDOC33/Section+elements ). This work was done in areas that were particularly important/high use, but are not everywhere. Also, I think some of the form fixes (tabbing, for example) will have to be handled in QuickForm. This may make it easier (if you can figure out ways of overriding the assembly of all forms to something more accessibility friendly).
3) I'm not totally clear on the use case for a 'role based system'. It seems to me that most of the work that is needed will not have any negative impact on non-accessibility users. The one (possible) exception could be a custom WYSIWYG editor, but that would be fairly simple to override based on hooks and drupal's existing roles system. Other than that, I would second the notion that you will be helping yourself and everyone else by focusing fixes on the core templates, and not duplicating work that will probably be of benefit to all users.
I'm really excited to see this work get done! Please let me know if you need any help in grasping the current template guidelines, and if there are specific modifications we could make to increase accessibility: http://wiki.civicrm.org/confluence/display/CRMDOC33/Template+Guidelines
I will start by fleshing out my idea of a role based system a little better. There are times were the great things being done with Java Script for example are great for visual users of the site. However these same functions may not work well for blind users. With a roles system we could check weather a role of the user currently using the system uses that function or uses a non-Java script alternative.
For example on the customization page for the adding a contact (admin/setting/preferences/display?reset=1) uses up and down buttons to change the order of fields and panes. For blind users they should be select boxes with weights.
I know that Drupal 7 has looked at these issues and I welcome suggestions of how to do this better with CSS or other methods as well.
For the record I am not a developer and we will be working with developers who will be doing the actual coding for this project. However, as we are planning what will be done it is possible that I will miss a better way to do things. As you said, there is the possibility of taking the JavaScript out of the HTML templates and this might better solve the problem.
In the next week or so I will be moving forward with taking our findings and ideas to our developer who will be moving this process forward.
Thanks for the thoughts and feedback.
-Steve
I too think it is great news that CiviCRM's accessiblity may see some improvement. It will help broaden the potential user base if organizations that want and need to be compliant with legislation regarding accessibility can consider it, and more importantly allow everyone to make use of CiviCRM sites.
It might be a good idea to focus first on identifying in concert with experts in the field and the core team the various technical issues and then agreeing on the best approaches to solving them. Some you mention are obvious like the labels, but others like how to handle javascript issues elegantly for all users are perhaps less clear. There are tradeoffs between being backward looking with regard to supporting only old standards versus forward looking towards approaches that are getting recognition as being best practices but are not yet legislated.
This posting has caught the attention of Everett Zufelt (http://zufelt.ca), a colleague of mine who leads up Drupal 7's accessibility efforts both as an expert in the issues and as a developer. Might be worth reaching out to him for assistance (http://zufelt.ca/contact).
Hi,
Just had a chat with a blind person, and he was telling me that having Role based approach is indeed a risk of having the "accessible" version lagging behind the "normal" one, and being broken on a regular basis because no one uses it. In general better to have one version that degrates gracefully.
This being said, having widgets that you can disable on a page is probably nice and useful for everyone (I for one would love to disable the wysiwg editor on civimail, it tends to be a little bit too creative on the html it generates for my taste). Eg. its tendency to convert links to the same site as relative ones, that doesn't work at all in an email.
Having that "Switch to plain text editor" feature implemented shouldn't be too complicated, it's done on this blog for instance.
BTW, they are using salesforce in their NGO. They have an accessible mode.
X+
Hi - would be great to get an update on this work