Support Accessible Slick

I don't currently work on it. Feel free to contribute. Thanks.

This is an excellent idea!

I've started taking a crack at this, although in hopes of minimizing disruption, I'm trying to support both the original and the Accessibility360 versions of the library. The Slick UI settings form will allow you to select which version of the library to use.

I've only gotten as far as updating the settings and the form, and (I hope) the library detection and status reporting. For the moment, I'm assuming the library will be located at libraries/accessible360--accessible-slick/slick/* -- which is the name that'll be used by default if using asset-packagist.org to install it with composer like so:

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    ]

        "installer-types": [
            "drupal-custom-profile",
            "bower-asset",
            "npm-asset"
        ],

        "installer-paths": {
            "docroot/core": ["type:drupal-core"],
            "docroot/libraries/{$name}": [
                "type:bower-asset",
                "type:drupal-library",
                "type:npm-asset"
            ],
            "docroot/modules/contrib/{$name}": ["type:drupal-module"],
            "docroot/modules/custom/{$name}": ["type:drupal-custom-module"],
            "docroot/profiles/contrib/{$name}": ["type:drupal-profile"],
            "docroot/profiles/custom/{$name}": ["type:drupal-custom-profile"],
            "docroot/themes/contrib/{$name}": ["type:drupal-theme"],
            "docroot/themes/custom/{$name}": ["type:drupal-custom-theme"],
            "drush/Commands/{$name}": ["type:drupal-drush"]
        },

composer require npm-asset/accessible360--accessible-slick:^1.0

As of now, it seems to work insofar as it produces a working slider that looks like the standard library produces. There are some options deprecated by the Accessibility360 version, and I believe some new ones added, so I've still got a fair amount of work to do, but this is a beginning I think.

OK, the asset-packagist.org copy of the library doesn't appear to be complete. This patch adjusts things a bit to use the official download from GitHub, with a directory name of "accessible-slick". It's now showing the pause/play button on autoplay as expected. Next/prev arrows are present but not visible; not sure what's up with that yet.

@wrd, thanks for the lead.

I was about to release a new one. Happy to include your works by then.
Looks good, but I haven't been able to review it properly, just minor CS nits:

 } else {

Should be:

 } 
else {

Correct me if these new non-core-library definitions at slick.libraries.yml file are really needed:

+accessible-slick.load:
+  version: VERSION
+  js:
+    js/slick.load.min.js: { weight: 0, minified: true }
+  dependencies:
+    - core/drupal
+    - core/drupalSettings
+    - core/jquery.once
+    - slick/accessible-slick
+
+accessible-slick.theme:
+  version: VERSION
+  css:
+    layout:
+      css/layout/slick.module.css: {}
+    theme:
+      css/theme/slick.theme.css: {}
+  dependencies:
+    - slick/accessible-slick.load
+
+accessible-slick.thumbnail.hover:
+  version: VERSION
+  css:
+    component:
+      css/components/slick.thumbnail--hover.css: {}
+  dependencies:
+    - slick/accessible-slick.theme
+
+accessible-slick.thumbnail.grid:
+  version: VERSION
+  css:
+    component:
+      css/components/slick.thumbnail--grid.css: {}
+  dependencies:
+    - slick/accessible-slick.theme
+
+accessible-slick.arrow.down:
+  version: VERSION
+  css:
+    component:
+      css/components/slick.arrows--down.css: {}
+  dependencies:
+    - slick/accessible-slick.theme

Along with their PHP lines:

+    $prefix = $this->config('library') == 'accessible-slick' ? 'accessible-' : '';
+
     if ($this->config('slick_css')) {
       $load['library'][] = 'slick/slick.css';
     }
 
     if ($this->config('module_css', 'slick.settings')) {
-      $load['library'][] = 'slick/slick.theme';
+      $load['library'][] = 'slick/' . $prefix . 'slick.theme';
     }
 
     if (!empty($attach['thumbnail_effect'])) {
-      $load['library'][] = 'slick/slick.thumbnail.' . $attach['thumbnail_effect'];
+      $load['library'][] = 'slick/' . $prefix . 'slick.thumbnail.' . $attach['thumbnail_effect'];
     }
 
     if (!empty($attach['down_arrow'])) {
-      $load['library'][] = 'slick/slick.arrow.down';
+      $load['library'][] = 'slick/' . $prefix . 'slick.arrow.down';
     }

This new Accessible option is all or nothing, so it would be more efficient to override them once SlickSkinManager::libraryInfoAlter at :
https://git.drupalcode.org/project/slick/-/blob/8.x-2.x/src/SlickSkinMan...

Like you already did for Slick core library:

+      $css_file = $this->config('library') == 'accessible-slick' ? 'accessible-slick-theme.min.css' : 'slick-theme.css';
+      $libraries['slick.css']['css']['theme'] = ['/' . $library_path . '/slick/' . $css_file => ['weight' => -2]];

Only now for the module's own libraries.

Basically what is needed is altering/ replacing the dependencies for these 3:

• slick/slick.load
• slick/slick.colorbox
• slick/slick.vanilla

from slick/slick to slick/accessible-slick, yet only done via SlickSkinManager::libraryInfoAlter. This way many of codes will be intact and follow the replacement, except those required.

Something like https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/src/BlazyAlter.p... at Blazy:

if (blazy()->configLoad('io.enabled')) {
        if (blazy()->configLoad('io.unblazy')) {
          $dependencies = ['core/drupal', 'blazy/bio.media', 'blazy/loading'];
          $libraries['load']['dependencies'] = $dependencies;
        }
        else {
          $libraries['load']['dependencies'][] = 'blazy/bio.media';
        }
      }

CMIIW, thoughts?

UPDATE: This alter also helps keeps sub-module (Slick Lightbox, Slick Browser etc.) dependencies intact without additional changes thanks to slick.load is being intact.

Thanks for the tips -- in all honesty, I have no idea what most of those libraries do; I was just trying to get everything to load and function. Your comments help me understand better. I'll take a crack at those changes today.

This should be closer to your suggestions. I still need to add/remove options based on the selected library, but first I'm trying to figure out why the prev/next buttons aren't visible.

Options should be functional now, though I'm not at all certain I approached this the best way. There's some code in the theme preprocessor to remove settings that aren't valid in the selected library (and also settings that are empty, to avoid writing empty strings into the json and overriding defaults).

It's probably also worth looking at the order in which I added the options into the settings form; there might be a better way to organize them.

But, apart from the aforementioned problem with the prev/next arrows being hidden, it seems to work at least.

That wasn't working as well as I thought. Instead, I've changed the defaultSettings function to unset() any settings that aren't valid for the selected library. The theme preprocessor is still removing some items from the $js array if they're empty.

One thing I'm not at all sure of is why the new settings and their defaults aren't being returned in the defaultSettings array. Perhaps because it didn't exist when I initially installed the module, so that the default optionset doesn't contain them? It doesn't seem to be doing any harm -- the settings work when I add them to the optionset (e.g., I can save the new "regionLabel" setting and get the expected result) -- but it makes me wonder what important thing I may have missed.

Regardless, this version is working better than the previous, and no longer throws warnings about deprecated options.

OK, last one for today. It looks like I needed to keep the code in the preprocessor as well as adding the code to the defaultSettings method to ensure deprecated options are removed even if they've been saved to an optionset already.

Thanks for digging deeper. Truly appreciated.

Just two minor issues:

• You may want to remove LICENSE.txt file, likely just Composer traces which doesn't happen with Git.
• To avoid repeating a long standing translation issue like this #3075838: Configuration translation disallowed HTML, we need to only keep CSS classes for these options:
  

  +    pauseIcon: <span class="slick-pause-icon" aria-hidden="true"></span>
  +    playIcon: <span class="slick-play-icon" aria-hidden="true"></span>

  This is still acceptable as you can easily add additional classes like:
  slick-pause-icon fa fa-pause, or something like that, etc.

  In this case two steps:

  • feed $variables['settings'] array with just autoplay, pauseIcon and playIcon as CSS classes via this method. Along with prevArrow and nextArrow. So these can be consumed here.
  • Manually add <span class="{{ settings.pauseIcon }}" aria-hidden="true"></span> and <span class="{{ settings.playIcon }}" aria-hidden="true"></span> into slick.html.twig anywhere within slick_arrow block.

The rest is better than what I expected. Once you verified working, we can commit this.

UPDATE:

• Added autoplay for the check.
• Changed pauseIcon to settings.pauseIcon
• Changed playIcon to settings.playIcon
• Also be sure to check for settings.autoplay before printing HTML.

Thank you! I'll make another pass this morning and see if I can address these.

Actually, before I proceed with the pause/play stuff, I want to make sure I'm understanding correctly.

By default, accessible-slick automatically inserts the pause/play button if autoplay is true and useAutoplayToggleButton is not false.

If we want to add the pause/play markup manually in the template, then probably what we'd have to do is:

• Check if autoplay is true
• If so, check if useAutoplayToggleButton is true
• If so, pass useAutoplayToggleButton = false to the javascript, to prevent accessible-slick from adding the markup automatically
• ...but pass settings.useAutoplayToggleButton = true to the template, along with the pauseIcon and playIcon values to use as classes, and add the markup there

Alternately, what if we used SlickFormatter->preBuildElements() to check whether pauseIcon and playIcon need to be set, and if so, use the classes from the settings to build the strings there and update the optionset settings in $build? Something like this:

    if ($build['optionset']->getSetting('autoplay') and $build['optionset']->getSetting('useAutoplayToggleButton')) {
      foreach (['pauseIcon', 'playIcon'] as $setting) {
        if ($classes = trim(strip_tags($build['optionset']->getSetting($setting)))) {
          $icon = $this->t('<span class="@classes" aria-hidden="true"></span>', ['@classes' => $classes])->__toString();
          $build['optionset']->setSetting($setting, $icon);
        }
      }
    }

This seems to work, and it allows the library to use its own default behavior if the optionset isn't overriding the related settings. The disadvantage I suppose is that the icon markup can't be overridden in the template, only the classes can be changed.

I'm including a patch that uses this approach, but if you prefer the other method I'll take a stab at that instead.

The hustle is due to translation issue :(

This causes module default values different from JS' ones. But worth the efforts.

The correct location for all (Views styles, formatters, custom) is not at SlickFormatter, but here:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.3/src/SlickManager...

SlickFormatter is limited for fields.

Steps:
1. Must exclude those keys (pauseButton, playButton) here due to different from JS, otherwise JS reads wrong value:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.3/src/SlickSkinMan...

2. Then put the markup into $js array so it should be processed automatically.
Please change this:
$build['optionset']->setSetting($setting, $icon);
into:
$js[$setting] = $icon;

Like here.

Only placed anywhere before this line:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.3/src/SlickManager...

Not crucial, but recommended if you can handle complexity.
Check if the class is similar or different to module default values.

If similar to module default value, unset the keys from the optionset. (I have no idea to unset these keys for now, might need to add a new method to Drupal\slick\Entity\Slick.php).
This way JS takes care of populating its own markups.

Only if different from module default value, then pass it to $js array:
$js[$setting] = $icon;

This way no ugly escaped markups in data-slick variables unless different from module default value.

Regarding the hidden prev/next arrows, adding something like this to the CSS seems to solve the problem in a pretty minimal way:

.slick-prev:before {
  content: "\276E";
}

.slick-next:before {
  content: "\276F";
}

IIRC, though, this is more similar to what we'd get if we could count on the slick font being present:

/** Keeps decent fallback for when slick-theme.css is disabled, even if dup. */
.slick-arrow {
  border: 0;
  border-radius: 50%;
  font-size: 0;
  height: 42px;
  pointer-events: auto;
  position: absolute;
  top: 50%;
  -webkit-transform: translateY(-50%);
  transform: translateY(-50%);
  width: 42px;
  background: rgba(255, 109, 44, 0.8);
}

.slick-prev {
  left: 10px;
}

.slick-next {
  right: 10px;
}

.slick-arrow:hover {
  background: rgba(55, 70, 91, 0.8);
}

.slick-arrow:active,
.slick-arrow:focus {
  box-shadow: none;
  outline: 0;
}

.slick-arrow::before,
.slick-arrow::after {
  pointer-events: none;
}

.slick-arrow::before {
  color: rgba(255, 255, 255, 1);
  font-size: 36px;
  font-size: 2.25rem;
  position: relative;
  top: 5px;
}

.slick-prev:before {
  content: "\276E";
  right: 2px;
}

.slick-next:before {
  content: "\276F";
  left: 2px;
}

I could add either of these into the patch if you think it's appropriate. If not we can add it to our own themes.

I normally disable default fonts, so no problems personally :)

But worried a disruption, unless you don't think so. Feel free to decide.

I'll open a separate issue and provide a separate patch...then people can try it out and see what they think.

Moved the code for the pause/play button into SlickManager. Thanks for the help on that!

I should be able to handle stripping out the setting if it looks similar to the default, but I'm having trouble finding the defaults for the new settings. Dumping self::defaultSettings(); in removeDefaultValues() provides a list of all the defaults that were in the schema and slick.optionset.default.yml before I began my changes, but none of the seven defaults I added. Story is the same after a fresh install. I feel like I must have missed something about defining them...any hints?

> but none of the seven defaults I added
Hmm, not so obvious before I test the patch, so far I just reviewed it. I will see testing it.
Assumed saving the form : /admin/config/media/slick/ui and clearing cache.

I might be wrong. Try reverting Slick::defaultSettings and removed these:

+    $library   = \Drupal::config('slick.settings')->get('library');
+    $settings = self::load('default')->options[$group];
+    if ($library == 'accessible-slick') {
+      unset($settings['accessibility']);
+      unset($settings['focusOnChange']);
+      unset($settings['focusOnSelect']);
+    }
+    else {
+      unset($settings['regionLabel']);
+      unset($settings['useGroupRole']);
+      unset($settings['instructionsText']);
+      unset($settings['useAutoplayToggleButton']);
+      unset($settings['pauseIcon']);
+      unset($settings['playIcon']);
+      unset($settings['arrowsPlacement']);
+    }
+    return $settings;

The correct location to massage the values would be on the saving stage:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.x/slick_ui/src/For...

At this place you can remove and adjust the values like cssEaseBezier.

Aside the template preprocess already did it as the last resort.

This reverts the changes to defaultSettings, adds a new "removeUnsupportedSettings" method to the form, and calls that method just before "removeWastedDependentOptions", which looks like a sensible way to handle that.

I see what you mean about massaging values and removing them if they're basically the same as the defaults in the validation process...however, I'm still not able to see my new settings in the defaultSettings array. I was thinking all the default values would be pulled from slick.optionset.default.yml, but clearly I'm mistaken about that.

And I forgot to attach the updated patch.

Let's narrow down:

We missed a hook_update:
1. to set default value for config
2. to set those 7 values into DB

The samples are at Blazy and Slick install files.
If that still fails bringing defaults, might be something else. At least one down.

Aha! Thank you again. I failed to test with a fresh install...with a fresh install, the options are present. I've added an update hook and now the options appear in my previous install as well.

I've added a bit of code so that the play and pause icon markup is only added to the javascript if the class string doesn't match the defaults. I believe it's now working as expected...but of course tests by someone with fresh eyes would be very helpful.

Thank you :)

Two more left, I think:
1. Can we make removeUnsupportedSettings static and public? There are 3 places need this method to DRY.
2. The test complaint SlickDefault lines,

+      'pauseButton'     => 'slick-pause-icon',
+      'playButton'      => 'slick-play-icon',

Is it playIcon or playButton?

Done and done (whoops). I kind of rerolled this against the latest commits to 8.x-2.x, as I noticed my diff was trying to remove some new stuff you'd added related to global loading. The result is working in my local environment but I'll want to make sure it still patches properly.

Edit -- seems to be OK.

Sorry, for not being clear. I reviewed it from cell and tobedwego early at 1.30 AM :)

> There are 3 places need this method to DRY.
Perhaps 2 steps here:

• Move removeUnsupportedSettings into b/src/Entity/SlickBase.php
• Replace all dup lines with Slick::removeUnsupportedSettings().

The final method may be:

+  public static function removeUnsupportedSettings(array &$settings = []) {
+    $library = \Drupal::config('slick.settings')->get('library');
+    if ($library == 'accessible-slick') {
+      unset($settings['accessibility']);
+      unset($settings['focusOnChange']);
+      unset($settings['focusOnSelect']);
+    }
+    else {
+      unset($settings['regionLabel']);
+      unset($settings['useGroupRole']);
+      unset($settings['instructionsText']);
+      unset($settings['useAutoplayToggleButton']);
+      unset($settings['pauseIcon']);
+      unset($settings['playIcon']);
+      unset($settings['arrowsPlacement']);
+    }
+  }

The dup lines to replace are at 3 places here:
1. b/slick_ui/src/Form/SlickForm.php. Your removeUnsupportedSettings is generic, so applicable here:

+      // Remove elements that aren't supported by the active library version
+      if ($this->library == 'accessible-slick') {
+        unset($elements['accessibility']);
+      }
+      else {
+        unset($elements['arrowsPlacement']);
+        unset($elements['instructionsText']);
+        unset($elements['pauseIcon']);
+        unset($elements['playIcon']);
+        unset($elements['regionLabel']);
+        unset($elements['useGroupRole']);
+        unset($elements['useAutoplayToggleButton']);
+      }

Should be:

+     // Remove elements that aren't supported by the active library version.
+    Slick::removeUnsupportedSettings($elements);

And:

+      // Remove settings that aren't supported by the current library
+      $this->removeUnsupportedSettings($settings);

Should be:

+     // Remove elements that aren't supported by the active library version.
+    Slick::removeUnsupportedSettings($settings);

With this change, we should remove the no-longer useful leftovers from b/slick_ui/src/Form/SlickFormBase.php:

-  /**
-   * The active version of the slick library
-   *
-   * @var string
-   */
-  protected $library;
-
-    $instance->library = $instance->manager->configLoad('library', 'slick.settings');

2. b/src/Entity/SlickBase.php:

public static function defaultSettings($group = 'settings') {
-    return self::load('default')->options[$group];
+    $library   = \Drupal::config('slick.settings')->get('library');
+    $settings = self::load('default')->options[$group];
+    if ($library == 'accessible-slick') {
+      unset($settings['accessibility']);
+      unset($settings['focusOnChange']);
+      unset($settings['focusOnSelect']);
+    }
+    else {
+      unset($settings['regionLabel']);
+      unset($settings['useGroupRole']);
+      unset($settings['instructionsText']);
+      unset($settings['useAutoplayToggleButton']);
+      unset($settings['pauseIcon']);
+      unset($settings['playIcon']);
+      unset($settings['arrowsPlacement']);
+    }
+    return $settings;
   }

Should be:

   public static function defaultSettings($group = 'settings') {
-    return self::load('default')->options[$group];
+    $settings = self::load('default')->options[$group];
+    self::removeUnsupportedSettings($settings);
+    return $settings;
   }

3.b/templates/slick.theme.inc:

-  $library   = \Drupal::config('slick.settings')->get('library');

-  // There are some settings that are deprecated in accessible-slick, and others that
-  // are only available in accessible-slick. We also need to make sure empty settings
-  // aren't included in the json.
-  if ($library == 'accessible-slick') {
-    unset($js['accessibility']);
-    unset($js['focusOnChange']);
-    unset($js['focusOnSelect']);
-  }

Should be:
+ Slick::removeUnsupportedSettings($js);

I guess that should be all. Hopefully we don't miss anything else.
Feel free to correct me in case I didn't put things correctly.

I would also appreciate extra reviews in case I missed the obvious before committing this.

Thanks again for your works.

Ah! My apologies, I think I was still waking up myself when I read that comment. Here's another attempt.

Thanks for all the help you've provided through this process. I'm getting a clearer picture of how some things work.

I noticed incompatibility/ side issues with the module provided arrows.
But we can fix/ adjust it later, no problem. Basically the arrow HTML markups appear to be different and need adjustments.

ATM, I only included few minor CS fixes in the commit along with similar CS issue leftovers.
And the fix for the undefined $path warning at SlickSkinManager::getSlickPath for when the new library is not in place.

Let's commit this for wider feedback regardless the arrows issue, and keep this open till the new release in case any additional stuffs need including.

Feel free to provide additional compatibility fixes in this thread, or new ones.

Thank you.

Added Remaining Tasks to the issue summary to fix the compatibility, or side issues.

Found another issue with unwanted anonymous DIV causing broken styling.

This issue appears to be related to Slick 1.9.0 which is not currently supported by this module due to different default values between versions.

This is an obvious proof, Accessible Slick took Slick 1.9.0 as the patron. And this module doesn't support it, yet, due to such breaking changes mentioned elsewhere.

Notice the first screenshot with broken styling as the consequence.

Solutions: Needs manual adjustments to the values as noted here: #3123787: [Slick 1.9.0] Fix ROWS setting default value & description (ROWS needs to be 0 instead of 1) / slick-slide has unnecessary wrappers

Trying to track down the issue with Slick 1.9.0, previously the unreleased/ unofficial master branch:

• With this issue, https://github.com/kenwheeler/slick/pull/3688, Slick had reverted from 1.9.0 to 1.8.0 due to known bugs (the ones mentioned in the summary, dots, etc.).
• Unfortunately, Accessible Slick appeared to fork the buggy version. This causes the Slick 1.9.0 issues inherited.

Solutions:
The "solution" at #3123787: [Slick 1.9.0] Fix ROWS setting default value & description (ROWS needs to be 0 instead of 1) / slick-slide has unnecessary wrappers is confusing, even to me who knew Slick fairly well since 2014.
We need a dynamic check, and adjust values accordingly. Since Slick 1.9.0 was removed, leaving us with Accessible Slick which still inherits the bugs from Slick 1.9.0. However we might still to check for Slick 1.9.0 for just in case the old master downloads were never updated.

We'll move it to a new thread, but mentioned here as it is now solely the issue with Accessible Slick for immediate awareness of the issue.

Regarding #35, are you thinking that if the Accessible Slick library is selected, that option should be forced to 0 automatically? Or should the warning message be updated to inform the user about setting it manually?

Willy-nilly, only if 1, better than confusing messages due to breaking slides.

At any rate at all versions, only if rows >= 2, it will start creating grid rows. 0 and 1 won't.

Details are here: #3220286: [Accessible Slick] Provide a check for breaking changes with Accessible Slick
Also the patch comments: #3220308: [Accessible Slick] Thumbnail navigation no longer navigate slides

OK, the asset-packagist.org copy of the library doesn't appear to be complete

What was the issue there?

Might we consider use of composer.libraries.json considered for the libraries if the npm asset source is working?

Thanks for this awesome work!

I guess we could recommend using something like this if we want to grab/manage the library via composer ...

"accessible360/accessible-slick": {
            "type": "package",
            "package": {
                "name": "accessible360/accessible-slick",
                "version": "1.0.1",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/Accessible360/accessible-slick/archive/refs/tags/v1.0.1.zip",
                    "type": "zip"
                }
            }
        },

I'd been testing this patch and it has been working great (until you resize the browser window).
I've been experiencing > 100% CPU utilization (and eventual tab crash) after resizing.

Update 1
That issue seemed to stem from another technique that was being employed to added a11y enhancements to an accordion.

Update 2
That issues still seems to persist when using admin menu (when the menu shifts on mobile breakpoints), when shrinking down to mobile. Can anyone else replicate that? Possibly still something else interfering, but I can't think of what it could be just yet.

Update 3
Finally tracked it down. Seems to have been the rows=1 setting. I had multiple slicks on a page where the problem was occuring and I missed updating the config in another location. Seems to be working good now!

#43, patches are welcome, thanks.
#44, yes, isolations will help narrow down. Try viewing it at incognito or anon users. Be sure to also opt-in the provided module solutions: keep module CSS enabled at Slick UI, choose a Skin even dummy named Default, and Aspect ratio.

#44 - Resolved. See notes in that edit.
#43 - Hope to get some time to add an MR at some point. Right now I'm installing the package through composer using the technique I described, but would definitely prefer the composer.libraries.json route. Just gotta get around to creating/testing it.

What's the current status on supported versions of Accessible Slick? I had no luck with 1.8.0 and actually found that only the latest master worked, but this seems contrary to what I'm reading in most of the issues here, so it would be great to have an updated recommendation in this thread (or on the module homepage) for people trying to implement this in 2022.

Slick UI - Library to use select addition:
Is the plan to add the Slick JS and CSS via composer? Otherwise the flexibility that this select adds will not really be available for Site Builders (non-coders). Although I'm not sure if there is a reason NOT to use the accessible version.

If composer is not an option, I'd be happy to help with documenting how to set up the libraries.

I checked out this issue to test a bit. It was easy enough to manually change the slick library and it seems to work for a simple slider with dots. Would it be helpful to get a patch for the composer inclusion? Or to just test out the slick options with the newer library?

> What's the current status on supported versions of Accessible Slick?
Still NW :) To avoid false expectations that things were fine while not. You can view relevant issues under Accessible Slick".

Technically 2 known issues:

• Arrows being screwed up. If you know CSS, this is not a big deal.
• Some behavior changes: clicking slides no longer advance/ move slides. No issues with this module, was just ditched by Accessible Slick, etc. If you value Accessibility, then this is no big deal, either.

And one bonus issue: Big Pipe screwed up CSS re-ordering, not strictly related to this issue, but things in CSS in general, including the above arrows issues.

Those issues are no issues of this module. But left NW, so you are aware we are aware of them.

> Is the plan to add the Slick JS and CSS via composer?
It was a request before, and the answer is still a No, sorry :)

Shortly, two: security and version preference.
If you built Slick since 2014, we had Security issues with Slick library, not Slick module. Hence why. Chasing up security issues that other people do is no joy. Aside libraries should be handled by builders at top level composer, not modules'.
I prefer Slick 1.6 which has less features, but less issues. People might want 1.8.0, etc. Enforcing particular version is no good.

For docs, improvements are always welcome as I am not a native speaker, stupid wordings are my birth rights.

Feel free to correct and or patch them.
Thanks.

I hope I'm not out of line with this suggestion, but people looking to meet accessibility requirements might consider gausart's closely-related Splide module. It's very similar in functionality, but the Splide library is accessible out of the box, and is being actively maintained. We've had pretty good luck switching our Slick formatters to Splide with very little extra work required.

Please can someone post a simple summary of which versions of the module, plus the slick and 'accessible slick' libraries need to be used to get this working.

Thanks

Sam

The latest Accessible Slick tested was 1.8.1. If any issues with the greater one, please lock it. Feel free to report here or at github.

The patch was already in the latest release that's why you failed applying it. No need reapplying it. The NW is not for the patch per se, but more to signal there are some minor problems outlined at #50 above which are less likely taken care of by this module. Above all to avoid unnecessary dups.

Hello, I'm trying to check out the patch in #31. Based on what I've read here, I should have an "Accessible Slick" option in the skins? I don't see this available after applying the patch. Do I need to do anything else to make the accessible version available?

> Do I need to do anything else to make the accessible version available?
More details are in my previous comments. You can enable it at Slick UI.

3.x is out.

Any betterment should start here and may or may not be backported later.

Thank you.

Morning, I am using
Accessible slick library 1.0.1
Slick library 1.8.0
Slick 3.0.3
Slick views 3.0.2
Blazy 3.0.10
Core 10.3.1

These are all upgrades for a slider I have had on my site for 2 years.

I have a content type Feature which a user adds content to then I have an entityqueue that is used to order the slides. this is all output in a slick view.

I have selected the accessible slick library and initially everything looks good with my custom optionset. But if I try and make a change to my custom optionset or just save the slick settings page with no changes then my slider breaks.

In the view settings I change the default optionset to Default then the slider works again (even after a save of slick settings)
For my current set up this works fine as I can override defaults in the view settings.

I am currently trying to find out why the view doesn't work with a custom optionset using the accessible slick library but haven't come up with a solution yet.

I have tried using Slick 1.6.0 library and also setting the rows to 0 but neither work.

Just incase this helps anyone or I am missing some steps?

Sorry, ignore #57. I found a setting called "Use group role" in the slick settings and checking this fixed my problem.

If you are using accessible-slick with Drupal 11, and therefore jQuery 4, you will need to patch the library to remove calls to $.type.
See the patch here: https://github.com/Accessible360/accessible-slick/issues/103

I think accessible slick might be our way out of #3467129: Incompatibility with Drupal 11/jQuery 4 and solve accessibility?

For now I've prepared:
"webksde/accessible-slick": "1.8.1",

{
      "type": "package",
      "package": {
        "name": "webksde/accessible-slick",
        "version": "1.8.1",
        "type": "drupal-library",
        "_readme": "!! PATCHED !! See https://github.com/webksde/accessible-slick/releases/tag/1.8.1-jquery4",
        "dist": {
          "url": "https://github.com/webksde/accessible-slick/archive/refs/tags/1.8.1-jquery4.zip",
          "type": "zip"
        }
      }
    },

based on https://github.com/Accessible360/accessible-slick/issues/110 (based on https://github.com/Accessible360/accessible-slick/issues/103)

But I'm not sure if the same issues still apply that were described with slick library > 1.6.0...

Might this allow us to solve responsiveness and the Drupal 11 jQuery issue maybe?