Publish accessible photo galleries

Prepare the story before uploading

Start with a useful gallery title and one or two sentences explaining what viewers will see, where, and why it matters. Choose an intentional order. Remove near-duplicates unless the change between them is part of the story, such as construction progress. Give each meaningful photograph its own alternative that reflects its role in the sequence. A visible caption can carry date, credit, or a more detailed note, so it does not need to repeat the alternative word for word.

When several images together communicate one idea, explain the idea once in nearby text and avoid making screen reader users hear the same description repeatedly. If an image is only a repeated visual detail, mark it decorative in the authoring tool when that is available.

Publish the editorial details

For each image, check the alternative, caption, credit, and any date or location against the source material. Do not put a full event notice or project update inside a photograph. If people are identifiable, follow the project’s approved photography and naming process; accessibility guidance does not create permission to publish personal information.

A static set of images is often easier to understand than an auto-advancing carousel. If a carousel is required, provide visible previous and next controls, a way to pause movement, a clear current-item status, and a predictable way to reach every image. Keep controls comfortably separated. WCAG 2.2 requires most targets to be at least 24 by 24 CSS pixels, with exceptions such as spacing, equivalent controls, inline links, unchanged user-agent controls, and cases where a particular presentation makes that target size essential, such as a dense map or data visualization, or where a legal requirement constrains it. A 44 by 44 CSS pixel control is a useful design practice for gallery buttons, especially on touch screens.

Hand off interactive behavior

Send the gallery URL and a short content checklist to the developer when it uses a slider, modal lightbox, lazy loading, or custom controls. The rendered component should have meaningful names and roles, a visible focus indicator, logical focus order, and a keyboard path to open, move through, and close the gallery. When a lightbox opens, focus should move into it and return to the launching control when it closes. The expected user outcome for a modal dialog is that Escape closes it; the developer should implement that behavior consistently and preserve focus return. Test at zoom and with reduced motion enabled. Keep an accessible fallback or page-level text so a script failure does not erase the story.