How to improve GLightbox when using AT / A11y?

[cmachanic]

First off, I really like this solution. Nice job!

I'm curious about how glightbox could provide better feedback to screen readers when the modal is opened? As of right now, it's silent when opening a photo with or without a caption. Maybe it would be nice to include an option for a string that got passed into a div? That div would only be meant for screen readers, so when the modal opens, it will provide some auditory feedback.

[cmachanic]

Now that I think about it, if we could add aria-haspopup="true" and aria-expanded="false" to each of the buttons/thumbnails, and then change aria-expanded to "true" when opened, and then back to "false" when closed, that would at least give the user some good auditory feedback. And then the only thing missing is getting the screen reader to announce the contents of the modal. Curious to know if others think that would work.

[janstieler]

Should you not post this at the issues tab because it's a Feature request?

[cmachanic]

That's totally valid. I guess it depends on how you look at it. I've been heads down in screen reader world, so I was seeing it as a bug for visually impaired users.

[janstieler]

For me also more than a feature because elements like lightbox have no semantic elments.
And a div construct is really hart to read or make it understandable for screenreader which kind of construct you have.

[gingerchew]

this is all very interesting to read. I've been wondering how the AT/a11y support is but wasn't sure how to test it.

i'm definitely down to exploring some solutions to come up with a better experience for AT users.

[cmachanic]

Yeah, I'm trying to wrap my head around this as well, and sorry, maybe this is more for a discussion (to @janstieler 's point). I've definitely found that running NVDA for testing as you build is super helpful. It's not that this stuff is super complicated. There's just no way of knowing how well something performs until you try to put yourself in a screen reader user's shoes, right?

I think applying focus to a predefined element in the modal (on load) could help (?). That way a screen reader will read it when it opens, and when the slide changes. Maybe that element (img, header, etc) is defined by a class we can apply in the markup? And then have that class get focus with each change in a slide? Just an idea.

I'm more on the UX/UI side of things, so I don't get too deep into JS, but it seems like you have a solid foundation in place for a lot of these details. Frankly, I think this could eventually be the nicest accessible lightbox out there.

[gingerchew]

I like the idea of the haspopup and expanded aria attributes being added. I am wondering how it is added though, one part of me says "let's take care of it for the developer and add it ourselves" while the other says "let's add it in the docs and really draw attention to it with an a11y section"

The balance between "all in one" and "developer friendly" is a weird one.

Either way, opening the modal should make some sort of announcement.

[gingerchew]

also tagging the other related issues: #352 #356

[onetrev]

Apologies in advanced if I'm wrong, but I thought discussion #366 should also be added to this discussion. It might also be worth noting issue #88 , while closed, it is related.

As I see it, there are two big items that would be nice to have for screen reader support, though the first one is already overcomeable with some quick JS (as I noted in #88 or by using the snippet in #366). The latter item I haven't been able to come up with a hack fix yet.

• Focusing on the first focusable element within the modal
• Trapping tab focus within the modal

Maybe as reference the Micromodal script could be useful? It tackles the key modal accessibility issues quite well I think, but overall is far less powerful and flexible as Glightbox. :)

[gingerchew]

I agree MicroModal does have a very sane way of handling it. Thanks for adding these to the a11y conversation 😊