Make accordion panels accessible

From https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752

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.

A user should be able to expand an collapse an accordion panel by using the keyboard only and not be required to use the mouse. To accomplish this, elements of crm-acordion-header should be made keyboard focusable and be configured to provide feedback to the screen reader on whether they are collapsed or expanded. At the simplest level, these elements could be made buttons instead of divs and be given the aria-expanded attribute which would be dynamically toggled depending on the panel’s state. This will allow a keyboard user to focus the panel header with the tab key and expand or collapse it with ENTER or SPACE. More in-depth examples of accordion accessibility can be found at OAA Accessibility http://www.oaa-accessibility.org/examplep/accordian1/, and Basic Accessible Accordion Panel for jQuery http://www.jqueryscript.net/accordion/Basic-Accessible-Accordion-Plugin-jQuery.html.

Technical spec to come.

Was https://issues.civicrm.org/jira/browse/CRM-20825

moved from accessibility#2 (moved)

Submitted PR https://github.com/civicrm/civicrm-core/pull/11955

added needs:concept approval in Accessibility - archived sig:accessibility triaged type:proposal labels

@monish.deb could you work on technical spec for this?

@JoeMurray @colemanw @bgm @eileen

Currently, CiviCRM accordions are not accessible, which means it doesn't fulfill WAI-ARIA compliance and these are the guidelines to make one. By making accessible means other then cursor options we can now rely on control keys to select/open/close an accordion. To do this, I found jQuery Accessible Accordion System (using ARIA) as the most recommendable JQuery plugin to make an accessible accordion. This plugin allows a user to expand an collapse accordion panel by using the keyboard only and not be required to use the mouse. Using ENTER or SPACE user can select and ENTER to toggle an accordion. Following are the steps to make accessible Civi accordion with the help of this new plugin:

1. Bower install the latest stable version of the new plugin and load the resources.

"jquery-accessible-accordion-aria": "^2.5"

2. Modify $.fn.crmAccordionToggle in order to use accordion() provided by this new plugin. Make changes in this function to indicate accordion panel, header and body. This is the basic HTML structure as per new accordion format

<div class="crm-accessible-accordion">
  <div id="panel1" class="crm-accordion-wrapper">
    <div class="crm-accordion-header">
      Header text
    </div>
   ... accordion body ...
  </div> // end of panel 1
  ...
</div>

Vs the old format

<div class="crm-accordion-wrapper">
  <div class="crm-accordion-header">
      Header Text
  </div>
  <div class="crm-accordion-body">
    ... content ... 
  </div>
  ...
</div> // end of crm-accordion-wrapper

3. Remove JS code specific to Civi accordion and bring necessary modification to retain old behaivour, like animate accordion dialog box on click.

4. CSS style changes

5. Modify accordions in template file as per the new HTML structure mentioned above.

Earlier I made some progress (https://github.com/civicrm/civicrm-core/pull/11955) in this direction, about making the accordions on 'Edit Individual' form, accessible and here's how it will look like:

Please provide your feedback and once this proposal got approved I will start working on it as per final spec.

On cividemo.jmaconsulting.biz Edit Contribution I am not able to get focus onto the accordions. Could you tell me how one is supposed to be able to do it?

We will need to create an additional issue for the accordion-like expansions used in various places in CiviCRM that are implemented with the little triangle icons to request show/hide. Eg on Contact Summary View, the custom fields, or on Contact Summary Contributions tab, to expand a contribution to show payments. These page elements tend not to currently have labels, so we will need to come up with appropriate names for them.

@JoeMurray, for now, I have only fixed the 'New Individual' form http://cividemo.jmaconsulting.biz/civicrm/contact/add?reset=1&ct=Individual as an example and will fix it for other forms once this spec got approved.

Yes will create a separate issue for such accordion-like expansions.

Thanks. Regarding the New Individual form: using tab doesn't go to next in series of accordions. Instead it currently only allows cycling through the accordions by entering one with tab, then using arrows. Looking at http://anvk.github.io/a11yAccordion/example.html, and following the approach we've chosen for supporting both arrows and tabs on menus, let's have tab and backtab cycle through accordions.

An impact of this is when tab from a previous screen element into set of accordions, focus should go to first accordion, not previously in-focus accordion. Similarly when back-tabbing, focus should go last of accordion series.

Otherwise, feels good.

@colemanw could we have approval for this proposal?

@colemanw ping

@colemanw ping - it's been a month.

Sorry for the delay. I've looked at this ticket a few times and every time I do I get this "uh oh" feeling about it and then get distracted by less daunting work, so now I'm going to take a moment to articulate why I feel that way: There are a lot of accordions in Civi core, and even more in the "universe" of extensions. Forcing a change to the markup of all of them is probably not practical. I'd like to find a backwards-compatible way to tackle this.

@monish.deb what about updating the code in common.js to find all .crm-accordion-header elements, adjust their markup with javascript, and the call the new plugin.

@colemanw @totten we're now having our similar reaction to your suggestion. So the difficulty is that even for the simplest part of the suggestion we can't see a feasible implementation.

As I understand the proposal (just checking), the idea is to find every <div class="crm-accordion-header"> and before it add <div id="panel1" class="crm-accordion-wrapper"> and then add an appropriate </div> after the closing </div> for crm-accordion-header. But this is not a simple parsing exercise that is appropriate for js - see second answer to https://stackoverflow.com/questions/2400623/how-do-html-parses-work-if-theyre-not-using-regexp (also https://stackoverflow.com/questions/4204136/does-anyone-have-regular-expression-match-javascript-function). I think trying to use something like a regex match (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match) is just not going to be up for the job of finding the closing </div>.

There is also the question of changing the js that converts the <div class="crm-accordion-wrapper"> into accordion, and also changing the js for the behaviours on the old to the new accordion libraries, etc.

If I understand the motivation here, there are two objectives you're seeking to meet:

1. Avoid edits to large number of files.
2. Use an approach that simultaneously upgrades the accordions in extensions to make them accessible.

My own assessment is that 1 will actually be more tedious but more feasible and performant. 2 could be dealt with by some approach that allowed the extensions to use the inaccessible accordions until the maintainers refactor their code.

A different approach (brainstorming here) might be to modify the existing Civi accordion logic in Common.js to make it accessible based on how the accessible accordion libraries do things. We could learn the latter by reading the code to understand how the new plugin works. In other word don't modify the html structure via js but make changes in js to add accessible behaviours. My assessment is that this is a risky, challenging alternative.

As mentioned, we're willing to pay CT for time spent on this. We're attempting to identify the tasks for you, and this seems to be one that we can't properly assess until we have a bit more of a shared vision on architecture. So consider work on this billable time.

@colemanw is this something we can look at for 5.31?

Did we find a way forward for this?

mentioned in issue user-interface#60

mentioned in issue user-interface#59

mentioned in issue marketing/events/european-events#2 (closed)

PR to add <details><summary>, implementing it for the news dashlet -> https://github.com/civicrm/civicrm-core/pull/28415

added has-pull-request label

mentioned in issue #4856 (closed)

More recent discussion on this is at dev/user-interface#60.

mentioned in issue #4986 (closed)

changed milestone to %5.73.0

I am closing this as DONE!!!

closed