Accessibility suggestions

[nicozerr]

I use NVDA everyday.
According to the initial issue, that's what I suggest:

1. Set the following attributes on the portal node:

   role="dialog" => OK
   aria-modal="true" => OK
   aria-live="polite" => No recommended, AT will vocalize dialog content twice if the root node has also aria-live=polite. In addition, when the dialog opens, its content will be also vocalized entirely.
   aria-roledescription="lightbox" => Not recommended, "dialog" role will be overridden by "lightbox". "lightbox" is a technical word, users are more used to ear "dialog".
   aria-label="lightbox" => mandatory, must manageable ("lightbox" can be changed into "our last event in pictures") and localizable.

2. Set the following attributes on the root node in inline (carousel) mode:

   role="region" => Even if i prefer role=group, "region" vocalization will be overridden by "carousel" from aria-roledescription.
   aria-live="polite" => OK
   aria-roledescription="carousel" => OK, to be manageable and localizable.
   aria-label="Photos gallery => Mandatory, must manageable and localizable.

3. Set the following attributes on individual slides:

   role="region" => Even if i prefer role=group, "region" vocalization will be overridden by "slide" from aria-roledescription.
   aria-roledescription="slide" => OK, to be manageable and localizable.
   aria-label="1 of X" => Mandatory and useful.

[ubermanu]

See #362

[igordanchenko]

Hi there!

Thank you for reaching out. I appreciate you taking the time to contribute to this library's accessibility improvements.

I have some follow-up questions for you.

2. Set the following attributes on the root node in inline (carousel) mode:

I'm assuming you suggest setting the role, aria-live, aria-roledescription, and aria-label attributes on the <div> element that holds all the slides (<div> element with the yarl__container class name), regardless of whether the lightbox is open in portal mode or inline mode. Can you confirm?

role="region" => Even if i prefer role=group, "region" vocalization will be overridden by "carousel" from aria-roledescription.

I chose role="region" based on the recommendation from the following guide.

aria-live="polite" => OK

Should this be switched to aria-live="off" during the slideshow playback? (that's when the Slideshow plugin is used)

3. Set the following attributes on individual slides:

role="region" => Even if i prefer role=group, "region" vocalization will be overridden by "slide" from aria-roledescription.

As I mentioned in the intitial issue, I ran into some issues with VoiceOver. I'll look into changing this to role="group".

I'll post my other questions as separate comments to keep this thread organized and easier to follow.

[nicozerr]

I'm assuming you suggest setting the role, aria-live, aria-roledescription, and aria-label attributes on the

element that holds all the slides (

element with the yarl__container class name), regardless of whether the lightbox is open in portal mode or inline mode. Can you confirm?

Yes, no matter the lightbox is in inline mode or portal mode.

I chose role="region" based on the recommendation from the following guide.

My fault, you're right.

Should this be switched to aria-live="off" during the slideshow playback? (that's when the Slideshow plugin is used)

Yes !!

As I mentioned in #350, I ran into some issues with VoiceOver. I'll look into changing this to role="group".

OK, thanks

[igordanchenko]

Do you have any recommendations for the "title" and "description" elements in the Captions plugin? Should these be assigned role="heading" and aria-level="1" / aria-level="2"? Are there any concerns that the "title" and image "alt" attribute may be identical and result in duplicate text announcements?

[nicozerr]

Heading not needed.
Just use something like a <p aria-roledescription="Caption"> tag or <div role=paragraph aria-roledescription="Caption">.
@ubermanu suggestedf it in his PR.

[ubermanu]

I've set the role=heading on the Title component as well, the same title will be used in the thumbnail to announce what image is going to be shown

[igordanchenko]

Should the slide counter element in the Counter plugin be marked as aria-hidden since aria-label="1 of X" will be present on each slide?

[nicozerr]

Yes I agree. I've pushed this change in @ubermanu PR

[igordanchenko]

Do you have any recommendations for the Thumbnails plugin? I haven't implemented any ARIA attributes on thumbnails yet.

[nicozerr]

Yes, @ubermanu will push the necessary changes.

[ubermanu]

Attributes added

[ubermanu]

TODO

• Set aria-live="off" with playback on and focused out of the carousel
• remove the gallery roles/wrapper if there is only one image/video

[igordanchenko]

"Rare" is not an option, accessibility is mandatory in France and may other countries.

Please do not twist my words, that's not what I said. By "rare" I meant a scenario of a lightbox with a single slide, nothing else.

"slider" or "gallery" implies control buttons, live region, content switching. If there's only 1 image/video, a screen reader or a braille display must not say "slider" or "gallery". So removing the role attributes is necessary.

Do you mind pointing me to this requirement in the carousel pattern guidelines?

Do you mind sharing a "gold-standard" carousel library implementing this pattern?

[ubermanu]

The thing is there are none, because a carousel is meant to be a set of multiple items

But a lightbox is a complete different story, it could also display a single image/video in the dialog (in case you have only one image/video)

But this brings side effects:

• The carousel wrapper should not announce anything (I think removing all the ARIA attributes should be enough)
• The aria-label on the slide should not announce its position (X of N)
• The Slideshow plugin should be hidden from the controls (since it is not necessary)

[ubermanu]

What would be the best approach here?

We could apply these changes at the carousel level (slide, etc...), even if it is not a carousel anymore?

[igordanchenko]

Here are my thoughts on this.

1. I'm more than happy to implement well-known requirements and well-established best practices. Still, the issue here is that I'm not finding any exemplary reference implementations following the requested approach. All the popular carousel and lightbox libraries I have checked so far either do not implement special handling for the "carousel with a single slide" case or (to my surprise) do not support accessible roles and labels at all. The same goes for popular photo management websites. That's why I asked for some reputable examples.

2. Given that the number of slides in a carousel or lightbox may dynamically change based on the user's actions, wouldn't it be confusing if the "carousel" role and "slide" labels suddenly appeared or disappeared in response to the user's input or actions? A slider displaying image thumbnails as part of an image picker or an image upload component would be one example. A lightbox displaying a fullscreen preview of the selected images would be another good example. Given that a user can select additional photos or remove some of the previously selected ones (even within the lightbox itself), the component may dynamically switch from a "multiple slides" to a "single slide" state in just one click of a button. Wouldn't the "carousel" role with the "1 of 1" slide label be more straightforward in this case?

[ubermanu]

1. It's a matter of perspective and UX at this point, there is no best practices at this point. You wouldn't find a carousel that does that because they don't want the hassle of it (or ignore a11y completely). Imagine you have a big box of cookies but when you open it, it only contains a single plastic-wrapped cookie; the box is useless wrapping for something you could have directly (sorry for the analogy I couldn't come up with a better idea hehe). Same principle apply here, if you click a single image to open the lightbox, people using assistive technology don't care if it's a carousel with one slide, they expect to see an image with additional info (title, caption...) and controls (download, zoom...), without the "carousel noise".
2. I agree with you on this, if the number of items can be dynamically updated, it is better to treat the thing as a carousel from the start since it's known that elements will be added

So in the end, it just ends up as preference, but so you know our position on this, is generally reduce as much unnecessary information transmitted to screen readers and such

We can keep the gallery as is, but we should remove it when possible