Question: Accessibility

[freddi301]

Hi, this component is exactly what I need. But is it accessible?

[richardscarrott]

Hi @freddi301 -- react-snap-carousel has a few advantages re: accessibility.

1. It's headless so you can markup the content however you see fit.
2. It uses native scrolling which most (all?) assistive technology should be comfortable navigating.

Personally I've only ever tested using VoiceOver for macOS which is more than capable of navigating the content in the carousel.

I've found it's best to simply hide the controls from screen readers as they aren't essential to navigation -- a user can just scroll using whatever input they prefer (mouse, trackpad, touch, screen reader etc.) -- in fact, without additional markup they just confuse screen readers in my experience.

e.g.

<div aria-hidden>
  <PrevButton />
  <Pagination />
  <NextButton />
</div>

[freddi301]

would you add an accessibility tips section to the readme? just copy pasting your answer is enough IMHO.
I agree contents are already accessible. from a brief analysis making controls accessible has not really a meaning: scroll controls are not useful for a screen reader, and this use case does not map to traditional pagination.
The only other thing that bothers me if the user uses tab to navigate the pagination controls, when he goes back to the content, it would scroll him to the beginning.
Feel free to close the issue if you don't think these are worth addressing.
Great work, best regards

[jonmilner]

I've found it's best to simply hide the controls from screen readers as they aren't essential to navigation -- a user can just scroll using whatever input they prefer (mouse, trackpad, touch, screen reader etc.) -- in fact, without additional markup they just confuse screen readers in my experience.

my understanding is that focusable elements (or elements that contain focusable elements) shouldn't use aria-hidden, because the elements remain focusable via keyboard navigation (but remain silent to screen readers, presumably causing more confusion).

it also appears it could be considered a level A violation (4.2.1)

one way to get around this could be to set the buttons and pagination to display: none unless the carousel is being hovered. assuming the carousel items are focusable (or have focusable children), tabbing through the items should in theory scroll the focused item into view, therefore remaining accessible via keyboard navigation.

[richardscarrott]

@jonmilner yeah I recall coming across the issue with aria-hidden and focusable elements when I last looked at this. I don't think adding display: none to the controls is a good idea as spoils the experience for everybody. I was hoping there was a media query to check if a screen reader is being used but AFAICT this doesn't exist.

I guess my original advice of adding aria-hidden was only really considering unsighted users and not considering partially sighted users who can potentially see the controls but still use a screen reader so it could be confusing.

It might be worth trying to make the controls accessible -- ultimately, I think you'd need to make sure the screen reader knows which elements in the list have become active as a result of navigating using the controls. I wonder if adding aria-current or aria-selected to the elements in the current 'page' would work?