WordPress gallery accessibility: WCAG 2.2 checklist

A gallery that a keyboard user cannot navigate, or that a screen-reader user cannot understand, is not “mostly accessible” — it is locked. Accessibility is binary at the point of use: either the person can operate the gallery or they cannot, and a beautiful gallery that traps a keyboard user is, for that person, broken. This matters more than photographers and shop owners tend to think, both because a meaningful share of every audience relies on assistive technology and because web accessibility is a legal expectation for businesses in many regions. WCAG 2.2 — the current standard, published in late 2023 — added three criteria that hit galleries directly, and most plugins have not caught up. This is the checklist.

It is the reference checklist; its hands-on companion, how to test whether your lightbox is actually accessible, shows you how to verify all of this yourself. Both sit under our gallery plugins guide.

Why gallery accessibility matters

Three reasons, in ascending order of how often they are forgotten. First, ethics and audience: people who use screen readers, keyboard navigation, or other assistive technology are part of every audience, and a locked gallery excludes them from your work or your products. Second, legal: web accessibility is increasingly a legal requirement for businesses, and image-heavy sites with inaccessible galleries are an obvious exposure. Third — the one most overlooked — accessibility and quality overlap: the things that make a gallery accessible (clear focus, keyboard operability, good structure) also make it better for everyone, including the sighted mouse user. Doing accessibility well is not a tax on the experience; it is part of a well-built gallery.

The three new WCAG 2.2 criteria that hit galleries

WCAG 2.2 added several success criteria; three are directly relevant to galleries and lightboxes, all at Level AA (the common compliance target).

• 2.4.11 Focus Not Obscured (Minimum) — when an element receives keyboard focus, it must not be entirely hidden by other content. For galleries this catches sticky headers or overlays that hide the focused thumbnail, and lightbox controls that obscure the focused element. The focused thing has to be visible.
• 2.5.7 Dragging Movements — any function that uses dragging must have a non-drag alternative. For galleries this affects drag-to-reorder admin interfaces and drag-based sliders: there must be a way to do the same thing without a drag (buttons, taps), since dragging is hard or impossible for some users.
• 2.5.8 Target Size (Minimum) — interactive targets must be at least 24 by 24 CSS pixels (or have adequate spacing). For galleries this hits the small lightbox close button, the next/previous arrows, and thumbnail navigation — tiny controls fail this, and they are common.

These three are new in 2.2, which is precisely why so many galleries fail them — they were built against the older 2.1 standard. They are also concrete and checkable, which makes them a good place to start an audit.

Alt text and the screen-reader experience

The foundation, predating 2.2: every meaningful image needs alt text so a screen reader can announce what it is, and decorative images need empty alt so the screen reader skips them (covered fully in alt text that ranks). In a gallery this scales — a 200-image gallery with no alt text is 200 images a screen-reader user experiences as “image, image, image.” Captions help too, read as part of the content. The screen-reader experience of a gallery is essentially: can the user move through it and understand what each image is? Alt text is what makes the second half possible.

Keyboard navigation

A keyboard user navigates with Tab (move between elements), Enter/Space (activate), and arrow keys (often, within a component). For a gallery this means: the thumbnails must be reachable and activatable by keyboard (Tab to a thumbnail, Enter to open it), and the lightbox, once open, must be fully operable by keyboard — navigate between images, and close, without a mouse. A gallery where you can Tab to thumbnails but cannot open or close the lightbox by keyboard is half-accessible, which is to say inaccessible for the keyboard user at the crucial moment. Full keyboard operability, end to end, is the bar.

The lightbox: the hardest part

The lightbox (the full-screen image viewer that opens on click) is where galleries most often fail accessibility, because a modal dialog has specific requirements that are easy to miss:

• Role and label — the lightbox should be marked as a dialog (role="dialog", aria-modal="true") with an accessible name, so a screen reader announces it correctly.
• Focus trap — while the lightbox is open, keyboard focus must stay inside it; Tab should not escape to the page behind. A lightbox a keyboard user can Tab out of (into the hidden page) is disorienting and broken.
• Return focus — when the lightbox closes, focus should return to the thumbnail that opened it, so the keyboard user is not dumped back at the top of the page.
• Escape to close — the Escape key should close the lightbox, as users expect of any modal.
• Announced image — the current image’s alt text should be announced as the user navigates between images in the lightbox.

Most gallery accessibility failures are lightbox failures — no dialog role, no focus trap, focus not returned, no keyboard close. They are invisible to a mouse user and total blockers for a keyboard user, which is exactly the kind of gap an audit exists to catch.

Colour contrast in captions and overlays

One more, easy to overlook: text over images. Captions, overlay titles, and controls placed on top of photos need sufficient colour contrast against the (variable) image behind them, which is harder than contrast against a solid background because the image changes. White text over a light photo, or a thin overlay that does not darken the image enough, fails contrast and becomes unreadable for low-vision users (and often for everyone in bright conditions). The fix is usually a sufficient scrim (a semi-opaque dark layer behind the text) or a text treatment that guarantees contrast regardless of the image. Check this against your lightest images, not your darkest.

The full WCAG 2.2 gallery checklist

• Alt text on every meaningful image; empty alt on decorative ones.
• Thumbnails reachable and activatable by keyboard (Tab, Enter).
• Lightbox: role="dialog" + aria-modal, accessible name, focus trap, return focus on close, Escape to close, current image announced.
• 2.4.11: focused elements not hidden by sticky headers/overlays.
• 2.5.7: non-drag alternative for any drag-based interaction.
• 2.5.8: interactive targets at least 24×24px (close, nav, thumbnails).
• Sufficient contrast for captions and overlay text over images.

The uncomfortable reality is that most gallery plugins do not pass all of this, particularly the lightbox criteria and the new 2.2 ones — accessibility is a place where plugins quietly differ a great deal, and “looks nice” tells you nothing about it. It is worth testing your current gallery against this list (the testing guide shows how) and treating accessibility as a real criterion when choosing a plugin, not an assumed default. A gallery built with these in mind — proper dialog roles, focus management, keyboard operability, adequate target sizes — serves every visitor and keeps you on the right side of both ethics and the law.