Jul 29, 2026

Before-and-After Image Sliders: The Drag-Only Widget That Fails WCAG 2.2

If you run a business that sells a visible transformation — a roofing company, a dentist, a landscaper, a med spa, a house cleaner, a car detailer — there is a very good chance your website has a before-and-after image slider on it. You know the one: two photos stacked on top of each other with a vertical handle in the middle. You grab the handle, drag it left and right, and the old photo wipes away to reveal the new one.

It is genuinely persuasive. It is also, in nearly every implementation I have tested, completely unusable for a meaningful slice of your visitors — and WCAG 2.2 added a success criterion in 2023 that speaks to this widget almost by name.

Here is what is going wrong, how to check your own site in about five minutes, and what your options are if it fails.

Most accessibility problems are sins of omission. Someone forgot the alt text. Someone did not label the form field. The before-and-after slider is different: it fails because of what it is. The entire interaction is built on the assumption that the user can see two images, understand that one is layered over the other, locate a thin handle, and physically drag it along a path.

That assumption breaks for a lot of people:

Someone using a keyboard only. People with motor conditions like tremor, Parkinson’s, or repetitive strain injury often cannot use a mouse reliably and navigate entirely with the Tab and arrow keys. If your slider handle cannot be reached with Tab, the widget simply does not exist for them.

Someone using a screen reader. If both images have empty alt attributes — and they usually do, because the developer treated them as decoration — the screen reader announces nothing at all. The visitor hears silence where your best proof of quality is sitting.

Someone with limited fine motor control. Dragging is one of the hardest gestures to perform. It requires pressing down, maintaining pressure, moving accurately, and releasing at the right moment. Someone using a head pointer, a switch device, or just a shaky hand may be able to tap fine and be entirely unable to drag.

Someone on a phone. Drag handles are frequently tiny, and on a touchscreen a horizontal drag competes with the browser’s own scroll and swipe gestures. Plenty of sighted, non-disabled people fail to work these on mobile too.

The WCAG 2.2 criterion that applies

When WCAG 2.2 was published in October 2023, it added nine new success criteria. Two of them land directly on this widget.

2.5.7 Dragging Movements (Level AA). This one is remarkably plain: if a function can be operated by dragging, there must also be a way to operate it without dragging — unless dragging is essential to the function. A single-pointer alternative, like clicking or tapping, has to exist.

Is dragging essential to a before-and-after comparison? Almost never. The purpose is to show two states of the same subject. Dragging is one way to reveal them; it is not the only way. A pair of buttons, a tap-to-toggle, or simply showing both images side by side accomplishes the same goal. Because a non-drag alternative is clearly possible, the “essential” exception does not save you.

2.5.8 Target Size (Minimum), also Level AA. Interactive targets need to be at least 24 by 24 CSS pixels, with some exceptions. Comparison slider handles are routinely thin vertical bars a few pixels wide. Even where the visible handle is small by design, the clickable region around it needs to meet the minimum.

Two older criteria are usually in play as well. 2.1.1 Keyboard (Level A) requires that all functionality be operable through a keyboard interface. And 1.1.1 Non-text Content (Level A) requires meaningful images to have a text alternative — and if you are using these photos as evidence of your work, they are meaningful, not decorative.

That is potentially four failures in one widget, two of them at Level A, which is the baseline that essentially every accessibility law and settlement references.

Test yours in five minutes

You do not need any tools for this. Open the page on your site that has the slider and do these four things in order.

One: try to reach it with Tab. Click once in a blank area near the top of the page, then press Tab repeatedly. Watch where the focus indicator goes. Does it ever land on the slider handle? If you Tab straight past the widget from the link above it to the link below it, the handle is not keyboard-reachable and you have failed 2.1.1.

Two: if you did reach it, try the arrow keys. With focus on the handle, press the left and right arrow keys. Does the divider move? If focus lands on the handle but the arrow keys do nothing, it is reachable but not operable — which is arguably worse, because now keyboard users get stuck on a control that does not respond.

Three: try to use it without dragging. With a mouse, click once directly on the left side of the image, then once on the right. Does anything happen? Many sliders support click-to-position; many do not. If the only thing that works is press-hold-move-release, you have failed 2.5.7.

Four: check what a screen reader hears. The quick version: right-click the before image and choose “Inspect,” then look for an alt attribute. Empty or missing means silence. The better version: turn on VoiceOver on a Mac (Command + F5) or Narrator on Windows (Windows + Control + Enter) and listen to what the widget announces as you pass through it. If you have never done this, our VoiceOver testing walkthrough covers it step by step.

In my experience the typical result is: not reachable by Tab, no arrow key support, drag-only, and two empty alt attributes. Four for four.

Your four options, from best to worst

Option 1: Replace the slider with two labelled images

This is the fix almost nobody considers and it is very often the right answer. Show the before photo and the after photo next to each other — or stacked on mobile — each with a visible caption reading “Before” and “After,” and each with real alt text describing what is actually shown.

There is no widget to break. It works with every screen reader, every keyboard, every input device, and every browser. It works if JavaScript fails to load. It is faster. And there is a business argument too: your visitor sees both states immediately instead of having to discover, understand, and operate a control to see the thing you wanted them to see. The slider is a small interaction tax you are charging every visitor for a bit of delight.

If your gallery has twenty projects, this is also dramatically less code to maintain.

Option 2: Keep the slider, add real controls

If you want to keep the interaction — and it is genuinely nice when it works — the widget needs to be built properly. In practice that means the handle behaves like a real slider control: reachable with Tab, movable with the arrow keys, with Home and End jumping to either end, and with an accessible name and current value that assistive technology can read. It also means clicking anywhere on the image repositions the divider, so dragging is never the only way, and the hit area around the handle is at least 24 by 24 pixels.

Some plugins do this correctly. Most do not. Before you ask a developer to build one from scratch, check whether your existing plugin already supports it — and test it, rather than trusting the feature list.

Option 3: Add a plain toggle button

A middle path that requires much less engineering than a properly built slider: keep the visual reveal for people who want it, and add an obvious button underneath labelled “Show before” / “Show after” that swaps the full image on click. One button, real text, focusable by default, works with a keyboard and a screen reader with no ARIA at all.

It is not elegant, but it satisfies 2.5.7 by giving a single-pointer alternative, and it is something a competent WordPress or Squarespace person can add in an afternoon.

Option 4: Fix only the alt text

If you can do nothing else this quarter, at least write proper alt text on both images. “Before: cracked and stained concrete driveway with weeds growing through the joints” and “After: resurfaced driveway with a smooth grey finish and clean edges” tell a screen reader user exactly what the widget is showing them without them needing to operate anything.

This does not fix the keyboard failure or the dragging failure. It is a patch, not a solution. But it converts the widget from invisible to readable, which is a meaningful improvement for a very small amount of work.

Writing alt text for before-and-after photos

This is worth pausing on, because it is the part people get wrong even when they try.

The instinct is to write “before” and “after.” That is not alt text; that is a label. The screen reader user cannot see either image, so telling them they are looking at “before” tells them nothing about what changed.

Describe the difference, in the terms your customer cares about:

Weak: “before photo”
Better: “Before: a bathroom with cracked beige tile and a rusted vanity”
Best: “Before: bathroom with cracked beige floor tile, water-stained ceiling, and a rusted vanity unit”

And the after image should describe the same features in their new state, so the contrast is obvious when the two are read one after the other. If your page shows twelve project comparisons, this is real writing work — but it is also the exact content that helps your search rankings, since accessibility and SEO overlap heavily.

What to say to your web person

If you are not the one editing the site, here is language you can paste into an email that will save a round trip:

Our before/after image sliders are drag-only, which fails WCAG 2.2 success criterion 2.5.7 (Dragging Movements, Level AA) and 2.1.1 (Keyboard, Level A). The images also have empty alt attributes, which fails 1.1.1. Can you either (a) replace them with side-by-side labelled images, or (b) make the handle keyboard-operable with arrow keys and add click-to-position so dragging is not required? Either way we need descriptive alt text on both images. Please confirm which approach you are taking and roughly what it costs.

Naming the specific criteria matters. It signals that this is a compliance item rather than a design preference, and it gives a developer something concrete to verify against.

Why this is worth your afternoon

Before-and-after galleries are almost always on the highest-intent pages of a service business’s website. They are the page someone visits right before they call you. Everything on that page is doing sales work.

A visitor who cannot operate your slider does not email you to complain about WCAG criteria. They just do not see the proof, and they call the next company on the list. The accessibility failure and the lost lead are the same event.

And unlike a lot of accessibility work, this one has an unusually cheap escape hatch. You are not being asked to rebuild your checkout or restructure your navigation. In many cases the correct fix is to delete a JavaScript widget and show two photos with captions — which is less code, loads faster, and works everywhere.

Test yours today. Tab to it, arrow through it, click without dragging, and check the alt text. Five minutes will tell you whether the most persuasive thing on your site is reaching everyone who visits.

This article is general information, not legal advice. For questions about your specific compliance obligations, consult a qualified attorney in your jurisdiction.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.