Provide an accessible variant

For reference - the motivation for this patch is that the approach considered in https://www.drupal.org/project/ckeditor_accordion/issues/2869510 actually violates HTML5.2 spec, which does not allow the necessary aria-attributes on dd & dt elements.

So we'd be exchanging violating one WCAG criterion (4.1.2) with another (4.1.1)

New patch that uses smillart.WAI-ARIA-Patterns-And-Widgets from root libraries folder. Also a new update on the README file regarding installation procedures.

I tested both patch 12 and 13.

Patch 12:

Does not seem to work after you did the fix to the path for the css file. Previous patches worked.

Patch 13:

Im getting the following error after enabling the ckeditor plugin under text formats:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\ckeditor_accordion\Plugin\CkeditorAccordionVariantManager are: ckeditor_accordion_variant_default in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

@mfv, Have you tried to remove the module folder and run composer install? My patch is not changing what has been done previously regarding the CkeditorAccordionVariant Plugin.

Addded new patch that changes WAI-ARIA-Patterns-And-Widgets library path.

@bprogrammer im not sure what could be causing that error. I deleted and reinstalled the module. Could be something with my local install, im testing this on 8.9.6 btw.

@mfv in my case I was testing on 8.8.3. I will try to test it on the latest 8.9 version and see if they same error arises on my side.

In the meantime I created a new patch that checks if the WAI-ARIA-Patterns-And-Widgets folder exists in /libraries before attaching it.

I'm reporting this for one of our clients so that it can be addressed. I've applied patch #19 via composer and it got applied without any issues. However I'm noticing the following issues that's blocking this module from being fully accessible:

1. Clicking through the accordion doesn't change the state of the ARIA attributes.
2. When testing the accordion in the VoiceOver screen reader, the ARIA states don't get announced. Only the link titles do.
3. Adding custom JS to accordion.js doesn't fix the issue.

When upgrading to ckeditor5 and also having Drupal 9.5 we would get a error where the filter would block our config import.
I have rerolled the patch so it applies on the 2.x branch, i haven't checked the functionality yet, but it solves our current issue.

Since there has been a new release and the patch doesn't apply anymore, here is a reroll.

I have a working patch for this version of ckeditor_accordion providing aria compliant tags and events. Which was scanned, audited and approved by the US Federal Government.

I rolled a Patch, built against 8.x-1.x-dev but I'm unsure where to merge or upload it?

Patch uploaded

ckeditor_accordion-provide-accessible-variant.patch

Demo is inspectable here: https://ncela.ed.gov/facilitating-online-learning

D10/CKEditor 5 returns an error (screenshot attached):

CKEditor 5 only works with HTML-based text formats. The "CKEditor Accordion" (filter_ckeditor_accordion) filter implies this text format is not HTML anymore.

The Standards for the Accessible rules define attributes and values which may not be "generic html" entities. But without it the menu will never validate nor be accepted by the US Federal and State governments requiring 503 compliance.

https://www.dol.gov/agencies/ofccp/section-503/compliance-assistance

The current releases including Ckeditor 5 on Drupal 10 is not compliant either.
But I'm not aware any other menu module is compliant at all either.

The new architecture for Drupal 10 is significantly different form this build so upgrading the patch would be seriously challenging for those contributes who didn't write the new module version. If anything can we create a feature request for the new version detailing the requirements and referencing the standards it would need to comply with to pass both government and 3rd party auditors?

I have updated the patch #22 to fix the issues on issue 3368096

Patch #30: Applied to D10: Getting an white screen of death on http://d10.local/admin/config/content/ckeditor-accordion:

Uncaught PHP Exception Error: "Class "Drupal\ckeditor_accordion\Form\Html" not found" at /Users/XXX/work/d10.local/web/modules/contrib/ckeditor_accordion/src/Form/CkeditorAccordionSettingsForm.php line 66

Patch #29:
can't be applied to v2.0

* Changing version to v2.0.x-dev as v8 is outdated

Fixing the error reported at #31

Hey, +1 for the issue and the work already done, to get some traction into this i just rebased origin/2.x into the issue fork, applied patch#32 on it (Had to reroll it because it didnt apply to CkeditorAccordionSettingsForm on tip of 2.x) and pushed into issue-fork, see https://git.drupalcode.org/issue/ckeditor_accordion-3124167/-/tree/31241... . Now we have the development in git i will start to review the work already done.

So I just realized that the release and tag 2.1.0 was made from the 2.0.x branch and is not reflected within 2.x (which would make sense afais) So right now the issue fork should have the state of latest release tag 2.1.0 + the rerolled and applied patch #32

So i tested on drupal 10.2.x-dev. Only thing that was pretty unintuitive was that the filter "CKEditorAccordion" had to be checked within the text-format...it took some time till i realized that it was missing.. i will add this part to the Readme. From then on it works pretty good IMHO +1

Did some further a11y testing with browser tools and WAVE, seems to work good, tried using screenreader "pericles" firefox extension which did not read the labels, only the contents but i dont know if thats a referrence.

Personally i can just add that the focus styles are barely visible, so its hard to see where you are when using keyboard navigation, which is not a big problem for me because i´m heavily overwriting the css anyway.

PS: I like the idea of the variant-plugin-system introduced here,
but there needs to be some further work done to be able to actually use it.
Right now it seems a little bit pointless because the WAI-ARIA-Patterns-And-Widgets library will always get loaded and has checks within itself for the element type, e.g "panel must be div", "heading must be H1-H6" so there is no point in making the element-types configurable when the accordion will not initialize then.
I´m thinking of extending the VariantPlugin with associated libraries that will be loaded according to the chosen variant.

to improve accessibility:

Header link <a class="ckeditor-accordion-toggler" href="#Accordiontitle" id="Accordiontitle" onclick="return false;" ...> is not really a link and requires proper aria attributes, eg role="button" aria-expanded="true" aria-controls="[id of DD element]"
to indicate this link controls a dd-element, it's a button and it's expanded

- if dd is collapsed, a-link element should have the following aria-attributes:
role="button" aria-expanded="false" aria-controls="[id of DD element]"

- dd/dl/link ids maybe duplicated if accordion is used in multiple fields on multiple similar structures - so maybe add a random number to ID to make sure it's unique

Hi everybody!

We use this patch on a hungarian website, but calling iconv() function with 'ISO-8859-1' value in the second parameter replaces special hungarian characters ( eg. 'ő', 'ű' ) with question marks.
I don't uderstand the code, but why is the iconv() call necessary?

We had an issue where we got the following error:
Notice: iconv(): Detected an illegal character in input string in /var/www/html/web/modules/contrib/ckeditor_accordion/src/Plugin/Filter/CKEditorAccordion.php on line 59

This resulted in text not being shown.

Adjusted it with examples from github and php.net

Drupal 10.2.7
Ckeditor 5
ckeditor_accordion 2.1.0

The patch causes a white screen of death on my build.
Especially once I enable the input filter.

composer package snippet

        {
            "type": "package",
            "package": {
                "name": "smillart/wai-aria-patterns-and-widgets",
                "version": "1.0.6",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/smillart/WAI-ARIA-Patterns-And-Widgets/archive/refs/tags/1.0.6.zip",
                    "type": "zip"
                },
                "require": {
                    "composer/installers": "^2"
                }
            }
        }

Ideally the interface of the accordion html would enable simple keyboard control of each accordion.
https://www.w3.org/WAI/ARIA/apg/patterns/accordion/

Having built a add-on module for the views_accordion module, having the header be a actual button tag enables basic keyboard control on click behaviors for opening and closing the content panel. Also adding tabindex="0" ensures it can be targeted by keyboard and screen readers.

Why is the arrow icon not using a ascii character over multiple before/after styles?

.ckeditor-accordion-container > dl dt > a > .ckeditor-accordion-toggle:before {
    content: "\2039";
    display: inline-block;
    position: absolute;
    left: 18px;
    -webkit-transform: rotateZ(180deg);  /* Chrome, Opera 15+, Safari 3.1+  */
    -ms-transform: rotateZ(180deg);  /* IE 9 */
    transform: rotateZ(180deg);
}

.ckeditor-accordion-container dl dt:hover .ckeditor-accordion-toggle:before,
.ckeditor-accordion-container dl dt.active .ckeditor-accordion-toggle:before {
    left: 12px;
    -webkit-transform: rotateZ(-90deg);  /* Chrome, Opera 15+, Safari 3.1+  */
    -ms-transform: rotateZ(-90deg);  /* IE 9 */
    transform: rotateZ(-90deg);
}

hmm,

I rerolled the patch and had to debug the code as it just didn't seem to be written to actually work. Anyway I fixed the bugs and I have it running on my local build and it's rendering using the ARIA principles!!

Wahoo!

Now who can actually commit this as a pull request and or get it releasable?

Embraced and extended code design and created a issue for 2.2
https://www.drupal.org/project/ckeditor_accordion/issues/3470583

As of version 2.1 now I get the following errors in the JavaScript console

accordion.min.js?v=1.x:2 Uncaught Error: Accordion constructor argument domNode has direct descendant elements that do not match with H2-H6 [data-aria-accordion-heading] or DIV [data-aria-accordion-panel] as required.
    at new o (accordion.min.js?v=1.x:2:7767)
    at accordion.min.js?v=1.x:2:10828
    at NodeList.forEach (<anonymous>)
    at accordion.min.js?v=1.x:2:10805

It would appear that the rendering of the input is somehow being overriden and the attributes are being stripped from the rendered accordion. The accordion still renders and the user can interact via keyboard and mouse.

But this error is posted to the console on page load.

Anyone familar with this and or how the new code highjacks the input rendering?

#49 works for me. Passes Axe Core automated testing. I also tested with keyboard and screenreader, and it all worked.

I tested with version 2.2 of the module.

I didn't see the issue in #50. Going to set this to Needs Review.

I'll note there is an open MR attached to this issue with commits from 9 months ago that has already fixed a lot of the issues from the last several comments/patches. I'd suggest anyone with issues test that MR and contribute back instead of creating separate patches.

With the latest 2.2.2 version I ran into an issue that the latest patch from #49 did not work anymore. So this is a patch for the latest version.

This patch appears to have lots of interest from the community. Any chance it will be merged into the module any time soon?

With the latest 2.3.0 version I ran into a issue that the latest patch from #53 did not applied correctly. So this is a patch for the latest version.

I rebased #48 to try to bring it up to date; however, after finding #3424786 I abandoned the effort (#3424786 seems like a more attainable approach).