How to test whether your gallery’s lightbox is actually accessible

Plenty of gallery plugins claim to be accessible. Some are; many are not; and “accessible” on a feature page tells you nothing, because the gap between the claim and the markup is exactly where galleries fail. The only way to actually know is to test — and the reassuring news is that you can do most of the meaningful testing yourself, in about fifteen minutes, with no screen-reader expertise required. This is the hands-on companion to the WCAG 2.2 accessibility checklist: that one is what to comply with, this one is how to verify you do.

Run these six tests on your own gallery (and on any plugin you are considering, by testing its demo). Each targets a real, common failure, and most need nothing but your keyboard and browser.

Test 1: the keyboard-only run

The single most revealing test, and the one to do first. Unplug your mouse, or simply commit to not touching it, and try to use your gallery with the keyboard alone. Press Tab to move through the page until focus reaches a gallery thumbnail (you should see a visible focus outline on it — if you cannot see where focus is, that is already a failure). Press Enter to open the lightbox. Use the arrow keys to move to the next and previous images. This sequence — Tab to thumbnail, Enter to open, arrows to navigate — is the basic keyboard journey, and a surprising number of galleries break somewhere in it (focus never reaches the thumbnails, or Enter does nothing, or the arrows do not work in the lightbox). If you cannot complete it, keyboard users cannot use your gallery.

Test 2: the focus trap

With the lightbox open (from test 1), keep pressing Tab. Watch where focus goes. It should cycle through the lightbox’s own controls (next, previous, close) and stay inside the lightbox — this is the “focus trap,” and it is correct behaviour for a modal. The failure is when Tab escapes the lightbox and starts moving through the page behind it (which is visually hidden but still receiving focus). If you Tab and the focus outline disappears into the page behind the open lightbox, the focus trap is missing — a keyboard user gets lost in a page they cannot see, which is disorienting and a clear WCAG failure. Watch the focus outline carefully; it tells you exactly where focus is.

Test 3: focus return

Open the lightbox from a specific thumbnail — say the fifth image — then close it. Watch where focus lands. It should return to the fifth thumbnail, the one you opened it from, so a keyboard user can continue from where they were. The failure is when focus is dumped somewhere else — usually back at the top of the page — forcing the keyboard user to Tab all the way down again to continue browsing. Lost focus on close is a common, subtle failure that makes a gallery exhausting to use with a keyboard even when everything else works. Close the lightbox and check: did focus come back to where you started?

Test 4: the screen-reader pass

This one sounds intimidating and is not. Every operating system has a built-in screen reader you can turn on for a quick check: VoiceOver on Mac (Cmd+F5), Narrator on Windows (Ctrl+Win+Enter), or use NVDA (free) on Windows. Turn it on, then navigate your gallery and listen. Two things to check: when you focus a meaningful image, does it announce a description (the alt text), or just say “image” or read a filename? And when you open the lightbox, is it announced as a dialog? You do not need to be a screen-reader expert to hear the difference between “Bride laughing during the first dance” and silence (or “DSC underscore 4 7 1 9”). The first is accessible; the second is not. A few minutes with the screen reader on tells you whether your alt text and dialog roles are doing their job.

Test 5: target size and contrast

Two quick visual checks. Target size: look at the lightbox close button and the next/previous controls — are they comfortably tappable, or tiny? WCAG 2.2 wants interactive targets at least 24×24 pixels, and a cramped little X in the corner often fails. The honest test is to try to tap the close button with your thumb on a phone; if you fumble it, it is too small. Contrast: check captions and overlay text against your lightest images (not your darkest) — white text over a light photo with no scrim is a common contrast failure that makes captions unreadable for low-vision users. Both are eyeball-level checks that take a minute and catch real WCAG 2.2 issues.

Test 6: automated tools (and their limits)

Automated accessibility checkers complement the manual tests but do not replace them. Run your gallery page through a tool like axe DevTools (a browser extension), WAVE, or Lighthouse’s accessibility audit — they will catch things like missing alt attributes, insufficient contrast (where measurable), and some ARIA problems, quickly and at scale. What they cannot reliably catch is the experiential stuff the manual tests target: whether the focus trap works, whether focus returns on close, whether the keyboard journey actually completes, whether the screen-reader announcement makes sense. Automated tools find roughly the issues that are mechanically detectable; the manual tests find the ones a real assistive-technology user would actually hit. Use both — automated for breadth and speed, manual for the failures that matter most.

Reading the results

Once you have run the tests, prioritise. A broken keyboard journey or a missing focus trap is a blocker — it makes the gallery unusable for a whole group of people, and it is the first thing to fix. Missing alt text is serious but easier to remedy (it is content, not code). Small target sizes and contrast issues are real but lower-severity, fixable with CSS and a scrim. The point of testing is not a perfect score but knowing your blockers from your nice-to-fixes, so you spend effort where it changes whether someone can use your gallery at all. If your current gallery fails the blocker-level tests and the plugin will not fix it, that is a strong signal to choose a different gallery — accessibility is a legitimate, testable criterion (see the plugin comparison), and now you have a way to test it before you commit.

This is also how to evaluate a plugin before installing it: run tests 1–3 on its live demo. A plugin whose demo lightbox you cannot operate by keyboard is one whose accessibility claims you can discount, regardless of what its feature page says. A well-built gallery should pass the keyboard journey, trap and return focus, close on Escape, and announce its images — testable in minutes on any demo, including FotoGrids’ own.