Access for Blind Users to CiviCRM
I am the Director of Organizational Technology for the National Federation of the Blind (the largest and oldest consumer organization of blind people in the US). We have used CiviCRM for a few years to collect data from our website. Since October 2015 it has become our primary member, donor, subscription, and event management database.

The majority of our users (blind or sighted) access CiviCRM through a “portal” we had custom developed. Mainly, this is because we are working to provide access to our affiliates and chapters  around the country and needed a way to containerize their access, but it did also provide a more accessible front end. However, myself and a couple other users do use the Civi backend with screen readers.

From the perspective of using Civi from the backend, I would say that an experienced screen reader user can learn the tricks required to use Civi. I’m a blind user and while I have encountered issues with the interface, I have successfully navigated most of them. In general, the following summarizes my experience with CiviCRM 4.6.5 and JAWS:


The menu bar is keyboard accessible, but awkwardly. Generally I find it best to focus on the first item then TAB (as opposed to arrowing) to the top level menu the user wants to interact with before pressing ENTER to activate the pop-up menu. You will then have to locate the HTML list element containing the menu choices. Often this element appears after the menu bar, or at the bottom of the virtual document (sometimes depending on the CMS theme, sometimes depending on, seemingly, the browser’s mood). In either case, it will not appear immediately “under” the activated menu.
The global contact search field has an autocomplete. While it does actually work with the keyboard, the information the screen reader reads when arrowing through the choices is the contact ID, not the name and other information that is visible on screen.
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demographic information, address, etc.) are collapsed by default. It is necessary to use the mouse (JAWS) cursor in order to expand these panels.
Civi makes use of the Select2 library in a number of places to generate certain pop-up lists. Basically, the library creates an edit-combo box (one where you have both a pre-defined list of options, but can also type in to narrow this list). While these elements are keyboard accessible, there are occasionally focus issues. As an example, choosing a date range  filter on searches offers selections like, “previous year,” but also allows the user to choose a date range. When selecting the choose a date range option edit fields appear next to the dropdown allowing the user to enter a start and end date range. However, for a screen reader user, pressing TAB after selecting this option will focus on the next group of fields, bypassing the date range fields. Although they don’t use Select2, this behavior is also observed with combo boxes that dynamically populate other combo boxes (like on the import data screens).
I think there are a couple places where fields lack proper labels, but I would need to hunt up specific examples.


I believe most of these issues also persist in 4.7, though we haven't upgraded our production install yet.

I do have web accessibility and development experience and ideas for fixing the issues I've identified. I'm happy to get more involved in CiviCRM development and work with anyone interested in broadening accessibility. We've been pretty focused on getting our install up and our two Civi databases merged, but I should now have more time to start contributing on the accessibility front.

In the interim I'm happy to discuss how I get around the present issues with anyone who needs that advice.

Rachel