9

Can you please tell me if CiviCRM is accessible by the blind using a screen reader ie; Jaws, Window Eyes or NVDA? If so were customizations required?

9

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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

2
3

CiviCRM is presented in the context of a CMS theme (Drupal, WordPress or Joomla) so it has to be assessed in that context. For that reason, there's no "yes/no" answer here, even having seen a11y reviews of sites we've built.

More importantly, assessing a11y requirements requires considering the context of the users - some CiviCRM installations may need only public (eg member / donor) facing frontpages to pass accessibility requirements, while others may need to consider needs of those using the CiviCRM backend as well. CiviCRM is a large project and there's a lot of interface to consider, and organisations use it differently (some have a single back-end user, some have many with varying levels of access to the system).

Currently, my answer would be that front-end forms can be configured to pass accessibility reviews for vision-impaired users, but I am not aware of any assessments of CiviCRM's backend interface. That's not a no - it's a "don't know".

1

(Merging in info from an earlier question: CiviCRM and screen reader software)

A client of mine tried unsuccessfully to use JAWS on the back-end and is just about to undertake some JAWS scripting. I'm encouraging them to consider sponsoring some development of the core product to address this.

The topic has been raised a few times over the years, but does not seem to have a good answer yet. For example:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.