swiper Accessibility issue with custom Navigation buttons

Check that this is really a bug

[X] I confirm

Reproduction link

https://codesandbox.io/p/sandbox/swiper-navigation-forked-jzzmnl?file=%2Findex.html%3A9%2C7

Bug description

When registering custom navigation buttons using Parameters as Props, the buttons are rendered outside the Shadow DOM created by swiper-container.

This is the correct behavior, except these outside buttons now have the aria-controls attribute pointing to a swiper-wrapper element inside the Shadow DOM. This is marked as a Critical accessibility error by tools like Axe or Lighthouse as the Id cannot be queried from outside the Shadow DOM.

I'm not sure what the solution is without tearing down the Shadow DOM altogether. Proposals like AOM's IDREF are promising, but it hasn't been supported by any browsers just yet. Alternatively, I can use Javascript to get rid of the aria-controls attributes, but this is just bypassing the WCAG spec.

Expected Behavior

No accessibility issues flagged by Accessibility tools.

Actual Behavior

aria-controls on custom navigation buttons are flagged as invalid.

Swiper version

11.1.1

Platform/Target and Browser Versions

MacOS 14.4 Chrome 124.0.6367.119

Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

May 13 '24 10:05 nhanvervio

I am experiencing the same issue as mentioned here.

Our custom button is being used outside of Swiper's Shadow DOM which causes an accessibility issue with the IDREF (ID + Aria-Controls) of the Swiper Wrapper element. Lighthouse also does not seem to like this issue resulting into a subtraction of 5 points within the Accessibility section.