DEV Community: AgentKit

Product Image Zoom and Lightbox Galleries: The Accessibility Trap in Almost Every Online Store

AgentKit — Thu, 30 Jul 2026 05:12:07 +0000

Here is an experiment that takes about thirty seconds and will tell you something uncomfortable about your online store.

Open one of your product pages. Don't touch your mouse. Press Tab until the focus outline lands on the main product photo, then press Enter. If a full-screen zoom view opens, press Escape. Then press Tab a few more times.

On a lot of stores, one of three things happens. The photo doesn't respond to Enter at all, so a keyboard user simply cannot see the zoomed detail your product page is built around. Or the zoom view opens and Escape does nothing, and Tab keeps cycling through links hidden behind the overlay that you cannot see. Or the overlay closes and focus has vanished — the next Tab drops you back at the top of the page, and you have to travel all the way down again.

None of these look like bugs when you use a mouse. All three are accessibility failures, and they sit on the single most important interaction on a product page.

Why the image gallery matters more than you think

For most e-commerce stores, product photos are not decoration. They are the product information. The fabric texture, the size of the connector, the shade of the paint, whether the strap is leather or leather-look — none of that is in the description. It is in the images, and specifically in the zoomed images.

This means the zoom view isn't a nice extra. It is where a customer decides whether to buy. When a shopper who navigates by keyboard, or who uses a screen reader alongside residual vision, or who zooms their browser to 300%, cannot reach it, they are not getting a slightly worse experience. They are being asked to spend money on something they were not allowed to look at properly.

It is also one of the most common patterns flagged in accessibility demand letters against retailers, for a simple reason: it is on every product page. One broken gallery component is not one issue. It is one issue multiplied by your entire catalog.

The five failures that show up over and over

1. The photo is not a real button

Most themes make the product image clickable by attaching a click handler to the image itself, or to a div wrapped around it. To a mouse, that works perfectly. To everything else, that element is not interactive. It cannot receive keyboard focus, it announces itself to a screen reader as an image rather than as something you can activate, and speech-control users who say "click zoom" have nothing to address.

What it should be: the thing you click is a real button (or link) containing the image. That single change gives you keyboard focus, Enter and Space activation, and a screen reader announcement, all for free, because browsers provide that behavior for native elements.

How to test: press Tab and see whether the focus outline ever lands on the image. If it never does, the image is not a button.

2. Escape doesn't close it

The zoom view is a modal — it covers the page and demands your attention until you dismiss it. Every modal on the web has an unwritten contract: Escape closes it. When your lightbox breaks that contract, a keyboard user's only exit is to find a close button they may not be able to reach, which brings us to the next problem.

How to test: open the zoom view, press Escape. It should close. Also check that the visible close button (usually an X in the corner) can be reached with Tab and activated with Enter.

3. Focus escapes behind the overlay

This is the one that catches nearly everyone. When the zoom view opens, keyboard focus needs to move into it and stay there until it closes. If it doesn't, pressing Tab walks focus into the page underneath — the header, the menu, the "add to cart" button, the footer links — all of which are now invisible behind the overlay. The user is tabbing through content they cannot see, with no indication of where they are.

For a sighted keyboard user this is disorienting. For a screen reader user it is worse, because they are being read a page that is no longer on screen.

What it should do: focus moves to the zoom view when it opens, Tab cycles only within it (image, next, previous, close), and when it closes, focus returns to the exact button that opened it.

How to test: open the zoom view and press Tab six or seven times slowly, watching the focus outline. If it disappears from the overlay and starts moving through the page behind it, that's the bug.

4. Focus is lost on close

Closing the zoom should put you back where you started — on the thumbnail or image button you activated. Instead, many lightboxes destroy the overlay and let focus fall back to the top of the document. A keyboard user who was halfway down a long product page now has to Tab through the entire header and navigation again to get back to where they were, and they have to do it every single time they look at a photo.

How to test: note which element had focus before you opened the zoom. Close it and press Tab once. You should land right after where you were, not at the top of the page.

5. Every image says the same thing (or nothing)

Product galleries are notorious for alt text that is technically present and practically useless. The whole gallery reads as "blue-tshirt.jpg" five times, or as the product title repeated identically for every shot, or as nothing at all because the theme left the field empty.

The point of a five-image gallery is that the images show different things. So the alternative text should too:

"Navy cotton t-shirt, front view"
"Back view showing the printed logo between the shoulders"
"Close-up of the ribbed collar and shoulder seam stitching"
"Model approximately 5'10" wearing size medium, relaxed fit through the body"
"Fabric close-up showing the visible weave texture"

That last pair does something a photo alone doesn't: it gives a blind or low-vision customer the fit and texture information sighted shoppers get by squinting at the zoom. It also reduces returns from everyone, which is the argument that tends to get budget approved.

Thumbnails are a separate case. If a thumbnail's only job is to switch the main image, its text alternative should describe what selecting it does ("View back of navy t-shirt"), not repeat the whole description.

The ten-minute audit

You don't need DevTools or any technical knowledge for this. Open a product page and work through the list.

Keyboard, four minutes. Unplug your mouse or just move your hands away from it. Tab to the main image and press Enter. Did anything open? Press Escape. Did it close? Reopen it and Tab several times — does focus stay inside the overlay? Can you reach the next, previous, and close controls? Close it and press Tab once — are you back where you started?

Zoom, two minutes. Set your browser to 300% (Ctrl or Cmd, plus the plus key, about five presses). Open the zoom view. Can you still reach the close button, or has it moved off screen? Is anything cut off with no way to scroll to it?

Screen reader, three minutes. On a Mac, press Cmd+F5 to start VoiceOver; on Windows, download NVDA free. Tab to the image button and listen. Does it announce something like "View larger image, button," or does it just say "image" or read out a filename? Then arrow through the gallery and listen to whether each photo describes something different.

Touch, one minute. On your phone, open the zoom view and try to close it. Is the close target big enough to hit reliably — roughly the size of a fingertip, not a 12-pixel X in the corner? Can you pinch-zoom inside it, or has the theme blocked that?

Write down what fails. That list is what you hand to whoever maintains your site.

What to actually ask for

The useful thing about these five failures is that they are all standard, well-solved problems. You are not asking for research. You are asking a developer to apply a pattern their tooling almost certainly already supports.

Send them this:

Our product image gallery has accessibility issues on every product page. Specifically:

The clickable product image needs to be a real button element, not a div or a bare img with a click handler, so it is keyboard focusable and announced correctly.

The lightbox needs to close on Escape.

Focus needs to be moved into the lightbox when it opens and trapped there while it is open, using aria-modal="true" with an appropriate role="dialog", and the background content should be inert.

On close, focus must return to the element that triggered it.

Every gallery image needs distinct, descriptive alt text, and the gallery CMS fields need to allow per-image alt text if they don't already.

This affects WCAG 2.1 success criteria 1.1.1 (Non-text Content), 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), and 2.4.7 (Focus Visible).

If you are on Shopify, Squarespace, WooCommerce, or Wix, check your theme's own settings first — some newer themes have already fixed this and let you swap the gallery style, which is faster than a code change. If your theme's gallery is broken and unmaintained, switching themes is sometimes genuinely cheaper than patching it. And if a third-party zoom or gallery app is the culprit, test a competitor before you pay a developer to work around it.

The part worth remembering

Almost no one audits their product gallery, because with a mouse it feels like the most polished part of the store. The animation is smooth, the zoom is crisp, everything works.

That polish is exactly why it goes unchecked for years, quietly turning the most persuasive part of every product page into a dead end for a slice of your customers. Ten minutes with your mouse pushed aside will tell you which side of that line you are on.

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

AgentKit — Wed, 29 Jul 2026 05:00:38 +0000

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.

Why this particular widget is such a reliable failure

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.

Sign in with Google, Apple, or Facebook: Why Social Login Buttons Fail Accessibility Tests

AgentKit — Tue, 28 Jul 2026 05:03:08 +0000

Social login buttons are the most copied-and-pasted element on the modern web. You add "Sign in with Google," maybe "Sign in with Apple," possibly Facebook or Microsoft, and you move on. The whole point of them is that they are supposed to be the easy part.

They are also one of the most reliable places to find a serious accessibility failure. Not a cosmetic one either. When a login button fails, the person does not get a degraded experience. They get locked out of their own account, on your site, permanently, with no way to tell you why.

Here is the frustrating part: social login is genuinely good for accessibility when it works. People with memory or cognitive disabilities, people using screen magnification who find password fields painful, people who struggle with a 16-character password containing a symbol — all of them benefit enormously from a one-tap sign-in. The idea is sound. The implementation is usually broken.

This guide covers what goes wrong, how to check your own site without technical skills, and what to say to whoever built it.

Failure 1: The button has no name a screen reader can read

This is the most common one, and it happens because of how these buttons get built. Google, Apple, and Facebook all publish official brand assets — and those assets are images. A developer in a hurry drops the image in, styles it as a button, and ships it.

To a sighted visitor, that image clearly says "Sign in with Google." To a screen reader, an image with no alternative text is either announced as the file name — "button, g underscore btn underscore light underscore normal dot png" — or as nothing at all. The user hears "button" and has no idea what it does.

The variant of this is the icon-only button: just a Google "G" or an Apple logo in a circle, no text. Visually it's obvious. Programmatically it's empty.

What to check: every login button must have a text label that a machine can read, either as visible text next to the icon or as a proper alternative description. WCAG 4.1.2 (Name, Role, Value) requires it, and WCAG 1.1.1 covers the image side.

A note on wording: the accessible name should say what the button does, not what it is. "Sign in with Google" is right. "Google" is not — nor is "Google logo."

Failure 2: The brand colors do not meet contrast requirements

Google's official light button is white with grey text and a thin grey border. Apple's guidelines allow white-on-white variants. These are designed by companies with large design teams, which leads people to assume they must be compliant.

They frequently are not, especially once someone modifies them. The two failures I see most:

Text contrast. The button label needs a 4.5:1 contrast ratio against the button background (WCAG 1.4.3). Grey text on white is often around 3:1 or worse, particularly once a designer lightens it "to match the brand."
Border contrast. If the only thing separating a white button from a white page background is a pale grey border, that border is doing the job of showing the button exists. It needs 3:1 contrast (WCAG 1.4.11). A 1-pixel #eeeeee line on white is about 1.2:1, effectively invisible to a lot of people.

This is a five-minute check with any free contrast checker. It is also one of the few accessibility issues you can fix yourself in most site builders.

Failure 3: The popup window nobody announces

Most social logins open a new window or popup for the provider's consent screen. This is where things quietly fall apart.

When the popup opens, focus may or may not move into it. Screen reader users often get no announcement that a new window appeared at all — they press the button, hear nothing, and reasonably conclude the button is broken. So they press it again. Now there are two popups, and the second one may fail with a "popup blocked" or session error.

WCAG 3.2.2 (On Input) is the relevant rule here: a change of context should not happen without warning. The fix is straightforward and rarely done — tell people in advance. Text on or near the button such as "Sign in with Google (opens in a new window)" costs nothing and solves most of the confusion.

There is a related problem on mobile, where the provider screen typically opens in an in-app browser or system sheet instead of a popup. That transition is usually handled better, but the return trip is not — which brings us to the next failure.

Failure 4: Coming back from the provider, focus lands nowhere

After the person approves the sign-in, your site reloads or the popup closes and the parent page updates. At that moment, one of three things should happen: the user is logged in and told so, or there is an error and they are told what it is, or they need to do one more step and they are told which.

What actually happens on most sites is that the page changes and focus resets to the very top of the document — or, worse, focus is lost entirely and the screen reader has nothing to read. A sighted user glances at the header, sees their avatar appear, and knows it worked. A screen reader user hears silence and has to manually re-read the whole page to figure out what state they are in.

What to ask for: after returning from the provider, move focus to a meaningful element — the confirmation message, the next required field, or the main heading of the logged-in page — and make sure the outcome is announced in text, not signalled only by an avatar image swapping in.

Failure 5: The dead-end error message

This is the one that turns an annoyance into a lockout.

The scenario is common. Someone originally signed up with an email and password. Months later they come back and tap "Sign in with Google" using the same email address. Many systems refuse this and return an error like: "An account with this email already exists."

Three things usually go wrong at once. The error is rendered as red text that is never announced to a screen reader, so the user does not know it appeared. The message does not say what to do next. And there is no link to account recovery from the error itself.

The result: the person cannot get in, cannot tell why, and there is nothing on screen guiding them out. Sighted users hit this too and find it irritating. Screen reader users hit it and have no signal anything happened at all.

What to ask for: login errors must be announced when they appear (an ARIA live region handles this), must state the specific problem, and must include the recovery action as a link — "This email is already registered with a password. [Sign in with your password] or [reset it]." WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion) both apply.

Failure 6: The keyboard path through the login box is a mess

Login boxes accumulate elements: a heading, two or three social buttons, an "or" divider, an email field, a password field with a show/hide toggle, a "remember me" checkbox, a submit button, and a "forgot password" link.

Tab through yours right now. Common problems:

The social buttons are <div> elements styled to look like buttons, so the Tab key skips them entirely. If you cannot reach a button with Tab, that button does not exist for keyboard users.
The focus indicator is invisible on the social buttons because the custom styling removed the browser outline. You are tabbing, but you cannot see where you are.
The tab order jumps around — social buttons, then the forgot-password link, then back up to the email field — because the visual layout was rearranged with CSS without changing the underlying order (WCAG 2.4.3, Focus Order).
The show/hide password toggle is an unlabeled eye icon that announces as "button."

Failure 7: Only offering social login

Some sites have replaced passwords entirely with "Sign in with Google or Apple." This is not itself a WCAG violation, but it is a real accessibility and equity problem worth naming.

Not everyone has one of these accounts. Some people avoid them deliberately for privacy reasons. Some corporate and school-managed devices block third-party sign-in. And if a person loses access to the provider account — which happens — every downstream account goes with it.

If social login is your only path, one broken button between you and Google means nobody can sign in at all. Keep an email-based path available.

How to test your own login in ten minutes

You do not need a developer or any special software for the first four of these.

Tab through it. Load your login page and press Tab repeatedly without touching the mouse. Can you reach every social button? Can you see where the focus is at all times? Can you activate a social button with Enter or Space? Can you complete the entire sign-in with the keyboard alone?
Zoom to 200%. Press Ctrl and + (or Cmd and +) until you hit 200%. Do the buttons still fit? Does the label wrap and get cut off? Is anything hidden behind a chat bubble or cookie banner?
Check the contrast. Screenshot the login box and run the button text and border through a free contrast checker. You want 4.5:1 for text, 3:1 for the border and any icon that carries meaning.
Trigger an error deliberately. Try signing in with a Google account whose email already has a password account. Read the error. Does it tell you what happened and what to do? Is there a link out?
Turn on a screen reader (VoiceOver on Mac with Cmd+F5, Narrator on Windows with Ctrl+Win+Enter). Navigate to each login button and listen. Does it say "Sign in with Google, button"? Or does it say "button," or read a file name? This one takes some getting used to, but the login page is a short and forgiving place to start.

What to send your developer or vendor

If you are on a hosted platform or working with an agency, the following list is specific enough to act on:

Every social login button needs an accessible name describing the action, not just the provider's logo image.
Button text needs 4.5:1 contrast; borders and meaningful icons need 3:1.
Add "opens in a new window" to buttons that launch a provider popup.
After returning from the provider, move focus to a meaningful element and announce the result in text.
Login errors must be in a live region, state the specific problem, and link to the recovery path.
All social buttons must be real <button> or <a> elements, reachable by Tab, with a visible focus indicator.
Keep an email-based sign-in path alongside social login.

If your login is provided by a third-party service (Auth0, Clerk, Firebase, Supabase, a Shopify or WordPress plugin), most of these are configuration or theme choices rather than custom code — and if the vendor cannot support them, that is a fair thing to raise with them directly, and worth checking before you sign a renewal.

The takeaway

Social login gets skipped in accessibility reviews because it looks like a solved problem. It is a button, it has a logo, it works when you click it. But it sits at the exact point where a failure costs the most — before the person can reach anything else on your site — and the failure mode is silent. Nobody emails you to say the sign-in button didn't announce itself. They just leave.

Ten minutes with the Tab key will tell you most of what you need to know.

Back to School, Nine Months to the Deadline: A School Website Accessibility Checklist

AgentKit — Mon, 27 Jul 2026 05:00:49 +0000

If you run communications for a public school or district in the United States, the new school year that starts in a few weeks is not just the start of a school year. It is the last full academic year you have before a federal accessibility deadline lands.

The Department of Justice's Title II web rule requires public entities to make their websites and mobile apps conform to WCAG 2.1 Level AA. Larger entities -- those serving populations of 50,000 or more -- were required to comply by April 24, 2026. Smaller entities and special district governments have until April 26, 2027. Which date applies to a school district generally depends on the population of the area it serves, so a district serving a small town is on the 2027 clock while a big-city district was already due last spring. If you are not certain which category you fall into, that is a question for your counsel, not for a blog post. (Nothing here is legal advice.)

Either way, the practical situation is the same for most district communications staff: you have one school year, no budget line for this, no developer on staff, and a website that hundreds of people publish to. Here is how to spend that year well.

Why school websites fail, specifically

School sites do not fail for exotic technical reasons. They fail because of how they are built and who publishes to them.

Every school in the district has a page. Every teacher has a page. The athletic department posts schedules, the PTA posts flyers, the business office posts board packets, food services posts menus, and the front office posts the bell schedule. None of those people are web professionals, none of them received accessibility training, and all of them are publishing under deadline pressure using whatever tool made it fastest.

The result is remarkably consistent from district to district. It is not broken code. It is thousands of documents and images that nobody can read unless they can see them.

The seven things to fix, in order of who gets hurt

I have ordered these by impact on a real family trying to get information, not by how hard they are.

1. The PDF problem

This is the big one, and it is not close. Lunch menus, school calendars, permission slips, registration packets, bus routes, board meeting minutes, athletic physicals, the student handbook, the newsletter -- on most district sites, the actual information lives in PDFs rather than on web pages.

Two things go wrong. First, many of these are scans. Somebody printed the lunch menu, signed it or stamped it, ran it through the copier, and uploaded the resulting image. There is no text in that file at all. A blind parent's screen reader announces nothing. Second, even PDFs generated digitally are usually exported by printing to PDF, which strips out heading structure, table headers, and the reading order, so the file is technically readable but practically a jumble.

What to do this year: stop uploading scans, without exception. If a document must be scanned, it needs to be replaced by the digital original. Then take your ten most-downloaded PDFs -- your web host or analytics can tell you which -- and republish that content as ordinary web pages instead of attachments. A lunch menu as an HTML table beats a lunch menu as a PDF for every single person, including sighted parents checking on a phone in a parking lot. For documents that genuinely must stay as files, author them in Word using real heading styles, add alt text to images, mark table header rows, set the document language, run the built-in Accessibility Checker, and then export using the accessibility export option rather than printing to PDF.

Do not try to remediate the whole library. Access is wildly concentrated. Fixing twenty documents will cover most of what anyone actually opens.

2. Flyers posted as images

This one is nearly as common and much easier to fix. Someone designs a flyer for the book fair, the fundraiser, or picture day in Canva or Publisher, exports it as a JPEG, and posts the image. Every word on that flyer -- the date, the time, the cost, the location, the deadline -- exists only as pixels.

A screen reader user gets nothing. Someone who zooms in gets a blurry mess, because images of text do not scale the way real text does. Someone on a slow connection gets a slow page. And the content is invisible to search, so a parent googling "picture day" on your site finds nothing.

What to do: post the details as text on the page, and use the flyer image as a visual accompaniment with alt text describing it briefly. Same information, same design, one extra paragraph of typing. This is the single highest-value habit change you can teach your building-level publishers.

3. Closure and emergency announcements

When you post a snow day, a lockdown notice, a late start, or a water main break, that information is urgent and it needs to reach everyone. On many school sites, the alert banner is a bright colored bar injected into the top of the page by JavaScript -- which means a screen reader user who has already started reading the page may never be told it appeared.

Check three things. Does the alert have enough color contrast to be readable, or is it white text on a light school-color background? Is the alert reachable and readable in a logical order, near the top of the page rather than buried in the markup at the bottom? And if the banner appears dynamically, is it announced? A parent should not have to discover a closure notice by accident.

Also check that the alert is not communicated by color alone. "The red banner means closure" fails for anyone who cannot see red.

4. Video without captions

Board meetings, superintendent messages, virtual open houses, graduation streams, athletic broadcasts, and recorded lessons. Uncaptioned video is a straightforward exclusion of deaf and hard-of-hearing families and students, and school video is the kind of content where auto-generated captions perform worst, because the vocabulary is full of staff names, school names, acronyms, and local place names.

What to do: treat automatic captions as a first draft, not a deliverable. Someone in the office reviews and corrects them before the video is published, focusing on names and acronyms. For long recordings like board meetings, post an agenda-linked summary or transcript so people can find the part they need without scrubbing through two hours of video. And if a video is required viewing -- a mandatory training, a required orientation -- missing captions should block publication, not go on a to-do list.

5. Staff directories and contact forms

The staff directory is one of the most-used pages on a school site, and it is often a wide table of names, roles, buildings, and email addresses built without header cells, so a screen reader reads it as an undifferentiated stream of text. If your directory is a table, it needs real header rows and columns so each cell is announced with what it means.

Contact and request forms have a related problem: fields labeled only by grey placeholder text that vanishes when you start typing, required fields marked with a red asterisk and nothing else, and error messages that appear visually but are never announced. When a form fails, the family cannot reach the school. That is a bigger deal than a styling bug.

6. Third-party embeds you did not build

Lunch payment portals, tuition and fee payment, athletic schedule systems, online registration, transportation lookup, the LMS login, calendar widgets, and enrollment forms. Districts run on vendor systems, and those systems are frequently the least accessible part of the site.

You cannot fix a vendor's code. You can do three things. Ask each vendor for their accessibility conformance report and actually test the embedded product yourself rather than filing the document. Put accessibility conformance into your next contract renewal and RFP, which is the only lever that reliably moves vendors. And in the meantime, publish a clearly visible alternative route -- a phone number, an email, a paper form available at the front office -- so a family blocked by an inaccessible portal can still register their child.

That alternative needs to be genuinely responsive, not theoretical. "Call the office" is only an accommodation if someone answers.

7. School colors and contrast

Districts brand their sites in school colors, and school colors were chosen for jerseys and gym walls, not for reading. Gold text on white, light blue on grey, or a navy-on-black footer all fail readability thresholds that people with low vision depend on.

You do not have to abandon the brand. You need a darker variant of the school color for text and buttons, and enough contrast between text and background. A free contrast checker will tell you in seconds whether a pair passes. While you are there, confirm the keyboard focus outline is still visible -- the ring that shows where you are when tabbing through a page. Designers frequently remove it because it looks untidy, which makes the site unusable for anyone navigating without a mouse.

A realistic plan for the school year

You are not going to fix everything, so sequence it.

August and September: Stop the bleeding. Send one short guidance note to everyone with publishing access covering three rules: no scanned PDFs, no flyers posted as image-only, and always use the heading styles instead of just making text big and bold. Three rules is something people will actually remember. Everything published from that point forward stops adding to the pile.

October through December: Fix the top twenty. Pull your most-visited pages and most-downloaded documents and work through only those. Republish the highest-traffic PDFs as web pages. Fix the staff directory table and the main contact form. Run a contrast check on the theme and get the school colors corrected once, centrally.

January through March: Vendors and video. Request conformance documentation from every third-party system on the site, test the important ones yourself, and get accessibility language into any contract coming up for renewal. Establish the caption review habit for board meetings and district announcements.

April: Re-check, and document what you did. A written record of your accessibility efforts and your remediation plan matters, both for your obligations and for the practical reality that this work is never finished.

One thing not to do

Do not buy an accessibility overlay widget -- the JavaScript products that promise instant compliance from a single line of code. They do not fix inaccessible PDFs, they do not caption your board meetings, they do not add alt text to flyers, and they do not make a vendor's registration portal work. What they do is add a visible accessibility badge to a site whose actual barriers are untouched, which is not a good position to be in. The money is better spent on the twenty documents.

The honest summary

A school district website is not hard to make accessible in a technical sense. It is hard because the content is produced by hundreds of people with no training and no review step, and because most of the important information is trapped in files rather than published as web pages.

The deadline is a forcing function, but the reason to do it is more ordinary than that. Somewhere in your district there is a parent who cannot read the lunch menu, a student who cannot follow the board meeting, and a family who cannot complete registration online. They have been working around your website for years. This is the year to stop making them.

The Drag-to-Filter Price Slider Is Quietly Locking Out a Chunk of Your Shoppers

AgentKit — Sun, 26 Jul 2026 11:01:13 +0000

You have almost certainly used one. You land on a shop's category page, glance at the sidebar, and there it is: a thin horizontal bar with two little circles you can drag toward each other to say "show me things between £20 and £80." It feels modern. It feels tidy. It saves space compared to a long list of price checkboxes.

It is also one of the most reliably broken controls in all of e-commerce, and most store owners have no idea, because it works perfectly the way they test it: with a mouse, on a laptop, with good eyesight.

Change any one of those three things and the price slider can go from convenient to completely unusable. For a shopper who navigates with a keyboard, a shopper who can't see the screen, or a shopper zoomed in at 300% on their phone, that friendly little drag control is often a wall. And unlike a lot of accessibility problems, this one sits right on the path to purchase. If someone can't filter, a lot of them just leave.

Let's walk through why this happens, how to tell if your store has the problem, and what "fixed" actually looks like -- all in plain language, no code required to understand it.

Why a price slider is harder than it looks

A price slider seems simple, but under the hood it's doing something genuinely tricky. A checkbox is either ticked or not. A dropdown is a list of fixed choices. A slider, by contrast, represents a range of continuous values and usually has two independently movable handles -- a minimum and a maximum -- that aren't allowed to cross each other.

That's a lot of state to communicate. To use the control, a person needs to know:

What am I even adjusting -- price? Rating? Something else?
Which handle is the minimum and which is the maximum?
What's the current value of the handle I'm touching right now?
What are the lowest and highest values allowed?
Did my last action actually change anything?

A sighted mouse user gets all of that for free, visually and instantly. They see the label above the slider, they see the two handles, they see the numbers update as they drag. The information is there, it's just delivered entirely through sight and pointer movement.

The trouble is that many sliders are built as decorative <div> elements styled to look like a track and two dots, with all the dragging behaviour bolted on for the mouse and nothing underneath telling assistive technology what any of it means. So when you take sight and the mouse away, there's simply nothing left to work with.

The three ways it breaks

1. Keyboard users can't move the handles at all

Try this on your own store right now. Click into the address bar, then press Tab repeatedly to move through the page without touching your mouse. Watch for the focus outline -- the ring or highlight that shows where you are.

When you reach the price filter, can you get onto the slider handles? And once you're there, do the arrow keys move them up and down? On a properly built slider, each handle is a stop on the Tab order, and Left/Right or Up/Down arrows nudge the value. On a broken one, Tab skips straight past the slider entirely, because those decorative dots were never made focusable. The handles might as well not exist.

For the millions of people who can't use a mouse -- because of tremors, limited hand mobility, repetitive strain injury, or simply because they navigate by keyboard out of preference or necessity -- a mouse-only slider is a dead end. They can see the filter. They just can't touch it.

2. Screen reader users hear nothing useful

Now imagine you can't see the screen at all, and a screen reader is reading the page aloud to you. A well-built slider announces something like: "Minimum price, slider, 20 pounds, minimum 0, maximum 500." You know exactly what you've landed on, which handle it is, and what you can do.

A poorly built slider announces... nothing. Or worse, it announces a meaningless jumble of <div> elements with no name, no role, and no value. The shopper hears an empty gap where a control should be. Even if the handles somehow are reachable, if the current value isn't spoken as it changes, the person is dragging blind -- adjusting a number they can never hear. There's no feedback loop, so there's no way to land on the price they actually want.

3. The handles are too small to grab -- for everyone

Even for sighted users, slider handles are frequently tiny: an 8-pixel dot floating on a 2-pixel line. On a touchscreen, that's a nightmare. Anyone with less-than-perfect dexterity -- and that's a huge group, including a lot of older shoppers -- ends up fat-fingering the wrong handle, grabbing the track instead, or dragging past their target and giving up.

WCAG, the international accessibility guidelines, ask for interactive targets to be at least 24 by 24 pixels for exactly this reason. A lot of theme sliders are well under that. This one isn't only a disability issue; it's a "why is this so fiddly on my phone" issue that quietly annoys a slice of every audience.

The 60-second test any store owner can run

You don't need tools or technical knowledge to catch the worst of this. Go to a category page on your own store and do three quick things:

The Tab test. Put your cursor in the browser's address bar, then press Tab over and over. When you reach the price filter, can you land on the handles, and do the arrow keys move them? If Tab skips the slider or the arrows do nothing, you've found the problem.
The zoom test. Press Ctrl and + (or Cmd and + on a Mac) until the page is at 400%. Does the slider still work, or has it collapsed, overlapped other content, or vanished off the side? Magnification users live at this zoom level.
The "is there a backup?" test. Look for two plain number boxes -- a "min price" and "max price" field you can type into -- sitting near the slider. If the slider is the only way to set a price range, that's a red flag. If there's a typed alternative, you have a safety net.

If your slider fails the Tab test and there's no typed fallback, a real portion of your visitors cannot filter by price, full stop.

What a genuinely accessible price filter looks like

Here's the reassuring part: fixing this is well-understood territory, and your fix usually falls into one of three buckets, from easiest to most thorough.

Option one: give people a typed alternative. The single most reliable fix is to make sure the slider is never the only way to set a price. Add two simple number input fields -- "From" and "To" -- with clear visible labels, right next to the slider. They stay wired to the same filter, so the slider and the boxes update each other. Now a keyboard user tabs into a field and types "20." A screen reader user hears "From, price, edit" and types a number like any other form. This alone rescues the feature for the people most likely to be shut out, and it's the kind of change a competent theme developer can make quickly.

Option two: use a real, properly labelled slider. If you want to keep the drag interaction, the handles need to be built as genuine slider controls, not decorative dots. That means each handle can receive keyboard focus, arrow keys change its value, and it exposes a proper accessible name ("minimum price"), a role ("slider"), and its current, minimum, and maximum values so a screen reader can announce them. Most modern accessibility-minded theme frameworks and reputable filter plugins already ship components that do this correctly -- the job is choosing one and confirming it, not inventing it from scratch.

Option three: reconsider whether you need a slider at all. For a lot of shops, a short list of sensible price bands -- "Under £25," "£25 to £50," "£50 to £100," "Over £100" -- as plain radio buttons or checkboxes is faster for everyone, trivially accessible, and easier on mobile than any slider. It's worth asking whether the slider is solving a real problem for your customers or just looking sleek in the design mockup.

Whichever route you take, the finish line is the same, and you test it the same way: tab to the control with the keyboard and set a range, run a screen reader across it and confirm it announces the label and values, and check it at 400% zoom. If a person can filter by price using only a keyboard, and again using only a screen reader, you've solved it.

Why this is worth your attention

It's tempting to file price sliders under "nice to have." But this is a control that sits directly between your visitor and the products they're trying to buy. Every shopper you block at the filter is a shopper who never reaches the checkout -- and in the EU under the European Accessibility Act, and in the US under the ADA, an online store that can't be operated without a mouse or without sight is exactly the kind of barrier that draws complaints and, increasingly, demand letters.

The good news is that price filtering is one of those problems where the accessible version is also just the better version. A typed min/max box helps the power user who knows they want something around £45. Bigger, easier handles help everyone on a phone. Clear price bands help the shopper who doesn't want to fiddle at all. Fixing this rarely means making the experience worse for anyone -- it means making it work for more people, which is the whole point.

Go run the 60-second test. If your slider fails it, you've just found a small, fixable change that quietly widens your entire funnel.

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

Memorial Day Sale Banners and Pop-Ups: Five Accessibility Mistakes Small Businesses Make This Week

AgentKit — Tue, 19 May 2026 11:00:45 +0000

Memorial Day weekend is six days away. If you sell anything online -- mattresses, patio furniture, candles, coffee, jewelry, art prints, a course, a software subscription, almost anything -- this is the biggest sale traffic week between Mother's Day and Father's Day. The promo will go up Friday morning, the email will go out Friday afternoon, the paid traffic will land Saturday and Sunday, and by Tuesday morning the sale will be over and the team will move on to the next thing.

The thing the team will not move on from is the sale banner code. It will stay on the homepage, slightly modified, until the Fourth of July sale uses it as a starting point. And whatever accessibility mistakes shipped in the Memorial Day banner are going to be on your homepage for at least the next six weeks, in front of every paid visitor you send to it, including the ones running screen readers, the ones using only a keyboard, and the ones with low vision who can barely see the discount code over your background photo.

This guide is for the person who actually has to put the banner up -- the owner, the marketing manager, the part-time web person, the one freelancer who knows how to edit the homepage in Shopify or Squarespace or WordPress. It is not for developers. There is no code in it. It is the five mistakes I see most often when I audit small-business sale pages in the week before a holiday weekend, and what to do about each one in under thirty minutes.

Mistake 1: The discount code is on a photo with no contrast

This is the first thing screen reader users do not even get to, because the bigger problem is that nobody with normal eyesight can read it either in bright sunlight on a phone.

The pattern goes like this. You have a beautiful product photo. White type goes over the top of the photo. Maybe the type is bold and big, so the designer assumes it is fine. It is not fine. White type over a busy photo fails WCAG 1.4.3 (Contrast Minimum, Level AA) almost every time, because the contrast ratio with the photo is variable -- some pixels are dark and the type is readable, other pixels are light and the type disappears entirely.

The fix that takes thirty seconds: put a dark, semi-transparent rectangle behind the type. The rectangle does not have to be opaque. Even sixty percent opacity over a busy photo is usually enough to bring the contrast ratio over 4.5:1, which is the WCAG Level AA threshold for normal text. Most page builders -- Shopify sections, Squarespace banner blocks, WordPress block patterns, Wix add-image-overlay -- have this as a one-click setting called "image overlay," "text overlay," or "background dimming."

While you are at it: do not put the discount code in the photo as part of the image. If the code is "MEMDAY25" and you bake it into the JPG of the lifestyle shot, screen reader users cannot copy and paste it, voice control users cannot dictate it, and search engines cannot index it. Put the code in real HTML text. The banner can still look great.

Mistake 2: The pop-up has no way to close it with a keyboard

This is the one that will get you a demand letter.

The pattern: a sale pop-up appears five seconds after the page loads. There is a close button -- usually a tiny X in the top-right corner -- that works when you click it with a mouse. It does not work when you press the Escape key. It often does not even appear in the keyboard Tab order, which means a keyboard-only user lands on the page, gets the pop-up shoved in their face, and now cannot reach the rest of the site at all. They cannot read the banner, they cannot reach the navigation, they cannot get to the product page, they cannot check out. The site is unusable until they close the tab.

This is a WCAG 2.1.2 (No Keyboard Trap, Level A) failure, and it is the single most common pattern that ADA Title III lawsuits cite in the demand letter. It is also one of the easiest things to test for yourself: open your homepage in a private browser window so the pop-up fires fresh, then press Escape. If the pop-up does not close, you have a problem. Now press Tab. If the focus indicator does not move into the pop-up first, and then offer you a focusable close button, you have a worse problem.

The thirty-minute fix depends on what built the pop-up. If it is a built-in Shopify or Squarespace newsletter pop-up, those are almost always keyboard accessible by default in 2026 -- just confirm. If it is a third-party tool like Privy, Klaviyo, OptinMonster, or Sumo, check the tool's accessibility documentation and make sure the latest version is enabled. If it is a custom pop-up your developer built three years ago, replace it with a built-in or first-party tool from your platform. Custom three-year-old pop-ups are almost never accessible and are almost never worth fixing.

Mistake 3: The countdown timer has no text alternative

If your Memorial Day banner shows "Sale ends in 02:14:36:18," that countdown is doing two things at once: it is creating urgency for sighted users, and it is creating absolute confusion for screen reader users.

The default behavior of most countdown timers is to update the displayed time every second. The numbers change in the DOM every second. If the timer is inside a screen reader live region (the kind that announces changes), the screen reader user hears "two days, fourteen hours, thirty-six minutes, eighteen seconds" being shouted at them every single second, forever, until they leave the page. If the timer is not inside a live region, the screen reader user often does not know it is there at all -- it appears as a stale, never-announced number.

Neither outcome is what you want. The fix is to give the timer one human-readable text equivalent that updates infrequently (once a minute is plenty) and that is exposed to screen readers in a polite live region (one that announces only when the user is idle). Almost no built-in countdown timer widgets get this right out of the box.

The practical answer for small businesses: if you must use a countdown timer, use one and only one, place it once on the page, and write a static text version next to it that says "Sale ends Tuesday, May 26 at 11:59 PM Eastern." The static date is what your screen reader users will actually rely on. The countdown timer is decoration. If your sale ends at a specific time, just say so in words -- urgency words work fine without spinning digits.

For more on this exact pattern, see our deep dive on countdown timer accessibility.

Mistake 4: The "Shop Now" button is a div with a background image

This one is invisible to almost everyone except screen reader users and the accessibility lawyer who is reading your source code for the demand letter.

The pattern: the designer made a beautiful CTA button. The developer rendered it as a <div> with a background image of the word "Shop Now" baked into it, often because it was easier than getting the custom font to render the same way across browsers. Sighted mouse users see a button, click it, and go to the sale page. Screen reader users hear nothing -- the div has no text content, no aria-label, no role -- and have no way to know there is a button there at all. Keyboard users cannot Tab to it because divs are not focusable by default.

This is a stack of WCAG failures: 1.1.1 (Non-text Content, Level A) because the image-as-text has no text alternative; 2.1.1 (Keyboard, Level A) because the control is not operable by keyboard; and 4.1.2 (Name, Role, Value, Level A) because the control has no accessible name or role. All three are Level A, which means failing any one of them blocks even the most lenient interpretation of WCAG conformance.

The thirty-minute fix: replace the div-with-background-image with a real <a> link or <button> element with the text "Shop Memorial Day Sale" written in real HTML. If you need the typography to be exactly the custom font, use the custom font as a web font, not as a baked-in image. Most platforms make this straightforward: in Shopify, use a Button section instead of a custom Liquid block; in Squarespace, use a Button block instead of a custom code block; in WordPress, use a Button block instead of a Custom HTML block.

Mistake 5: The exclusive email-only code is gated behind a CAPTCHA

This is the one where small businesses unintentionally lock out the customers they most want.

The pattern: to get the "exclusive Memorial Day code," the visitor has to enter their email in a form, then solve a CAPTCHA, then wait for the confirmation email. The CAPTCHA is usually the old-style "identify all the traffic lights" image challenge from Google reCAPTCHA v2, which is essentially unusable for blind screen reader users (the audio challenge is poor quality and inconsistently available), is exhausting for users with cognitive disabilities, and is broken on mobile for users with low motor control. You have just put a wall between your sale and the customers most willing to give you their email.

This is a WCAG 1.1.1 failure when the CAPTCHA has no accessible alternative, and it is also a practical conversion problem -- ten to fifteen percent of users abandon any form that requires a visual CAPTCHA. The fix is to use a modern CAPTCHA that does not require user interaction (Cloudflare Turnstile, hCaptcha invisible mode, reCAPTCHA v3) or to use a honeypot field that catches bots without troubling humans.

For more on CAPTCHA alternatives that do not block real customers, see our guide to CAPTCHA accessibility alternatives.

A thirty-minute Memorial Day weekend audit checklist

Before Friday morning, walk through your homepage one time. Put the mouse on the other side of the desk. Then:

Look at your sale banner. Is the discount code real HTML text on top of an image with a dark overlay? If not, add the overlay and move the code into HTML.
Trigger the pop-up by opening the homepage in a private window. Press Escape. Did it close? Press Tab from the address bar -- did focus go into the pop-up and offer a close button?
Look at any countdown timer. Is the actual end date and time written next to it in plain words? If not, add the date.
Tab through the page. Does every visible "Shop Now" or "Add to Cart" button receive a visible focus indicator when you Tab to it? If a button is skipped entirely, it is not really a button.
Sign up for your own email list using the sale form. Did you encounter a CAPTCHA? Was it the kind that asks you to click pictures? If so, switch to an invisible CAPTCHA or honeypot.

If you do nothing else this week, do those five things. None of them require a developer. All of them protect the paid traffic you are about to spend money on, and any one of them is the kind of fix that turns a demand letter into a non-event.

What to do after the weekend

When Memorial Day weekend is over and the sale comes down, leave yourself a calendar reminder for Wednesday afternoon to do the same five-step audit on the next promotional banner -- the one you will put up for Father's Day or for your summer sale. Most small businesses ship the same accessibility mistakes on every promo banner they run because the mistakes are baked into the template the first time and copied forward. Fix the template once and you fix every banner for the rest of the year.

This is also the moment to think about whether you have ever had your homepage audited end-to-end, not just the sale banner. Sale banners are the highest-visibility surface, but the checkout, the contact form, and the navigation are where most ADA Title III lawsuits actually land. If you have never had a proper audit, start with our five-minute accessibility audit and use it as a self-test before you commit to a paid one.

Why Your 'Added to Cart' Toast Notification Never Reaches Screen Reader Users (And the Two-Line Fix)

AgentKit — Mon, 18 May 2026 05:00:46 +0000

You add something to your cart on a Shopify store and a small message slides in from the top right of the screen. "Item added to cart." It stays for three seconds, then fades away. The product page never reloaded. The cart icon updated a count. Everything feels smooth.

Now do the same thing with a screen reader running. The screen reader announces the button you clicked — "Add to cart, button" — and then nothing. No confirmation. No announcement that the item was added. No indication that anything happened at all. The cursor stays where it was. Three seconds later the visual confirmation has already disappeared from the screen, but the screen reader user never knew it existed.

This pattern is everywhere now. Cart confirmations. "Changes saved" banners in dashboards. "Message sent" notices on contact forms. Email signup confirmations. "Coupon applied" notifications at checkout. Login error messages that appear without a page reload. Almost every interactive surface on the modern web uses some version of a toast notification or snackbar to confirm that an action happened.

And almost every implementation of this pattern silently excludes screen reader users from confirmation.

This is the kind of accessibility failure that does not show up in a Lighthouse audit. It does not show up in axe DevTools. It does not show up when your developer manually reviews the page in Chrome. It only shows up when someone who actually uses a screen reader tries to use your site, gives up because nothing seems to be happening, and goes somewhere else. By that point you have already lost the sale and the customer has already added you to their internal "sites that do not work" list.

The good news is that fixing this is one of the smallest, cheapest, highest-impact accessibility improvements you can make. It is often two attributes on one HTML element. If you understand the pattern, you can usually fix it without rewriting anything.

What a toast notification actually is

A toast notification (named after toast popping out of a toaster) is a small message that appears temporarily, then disappears. Snackbar is the same concept from Google's Material Design. Both are used for transient confirmations.

The visual pattern is consistent: a small box appears at the top, bottom, or corner of the screen, contains a short message, optionally has an icon, optionally has a dismiss button, and disappears on its own after a few seconds. The user does not have to click anything for the confirmation to go away.

The reason developers love this pattern is that it is non-blocking. Modal dialogs interrupt the user and require a click to dismiss. Inline error messages require the user to scroll to find them. Toast notifications appear, communicate, and leave without demanding anything. They feel polite.

But "non-blocking" is the same as "easy to miss." For a sighted user who happened to glance at the corner of the screen, the toast registers. For a sighted user who was looking at the cart icon when the toast appeared in the corner, the toast does not register. For a screen reader user, the toast might as well not exist at all unless it has been built to announce itself.

The accessibility failure is not that the toast is temporary. It is that screen readers do not, by default, announce content that appears in the DOM after the page loads. The screen reader is busy reading whatever the user is currently focused on. Content that quietly appears off in the corner of the page does not interrupt the reading flow unless you specifically tell the screen reader that this new content is important enough to announce.

The two-line fix: aria-live

The W3C built an ARIA attribute specifically for this. It is called aria-live, and it tells assistive technology "when content changes inside this region, announce the new content to the user."

There are two values that matter:

aria-live="polite" — wait until the user is between sentences or has paused, then announce the new content.
aria-live="assertive" — announce the new content immediately, interrupting whatever the user is currently hearing.

For most toast notifications, polite is the right choice. The user does not need to be interrupted mid-sentence to hear that their cart was updated. They will hear the announcement at the next natural pause. assertive is appropriate for genuine errors that the user needs to know about before they continue — for example, "Your session has expired and your changes were not saved."

The fix looks like this:

<div aria-live="polite" id="toast-region">
  <!-- toast messages get inserted here -->
</div>

When your JavaScript updates the inner HTML of that div with the toast message, the screen reader will announce it.

That is the fix. Two attributes. One element. The visual styling of the toast does not change. The behavior for sighted users does not change. The only thing that changes is that screen reader users now hear what just happened.

The subtle part: where the region lives matters

The reason this trips people up is that aria-live regions are picky about timing. If you create the region and add content to it in the same JavaScript tick, screen readers sometimes miss the announcement. The region needs to already exist on the page when the new content is inserted.

The correct pattern is:

On page load, create an empty live region in the DOM, typically at the bottom of the body or in a wrapper near the top.
Style it however your toast notifications look — corner placement, drop shadow, fade animation, whatever.
When you need to announce something, insert the message text into the existing region.
After the toast disappears visually, remove the text from the region.

Here is a working HTML and JavaScript example:

<div aria-live="polite" id="toast-region" class="toast-region"></div>

<script>
  function showToast(message) {
    const region = document.getElementById('toast-region');
    region.textContent = message;
    setTimeout(() => {
      region.textContent = '';
    }, 4000);
  }

  // Example usage when the "Add to cart" button is clicked:
  document.querySelector('#add-to-cart').addEventListener('click', () => {
    // ...add the item to cart via your existing logic...
    showToast('Black wool scarf added to cart. Cart total: 3 items.');
  });
</script>

A few details that matter:

Use textContent, not innerHTML. Setting textContent triggers the live region announcement more reliably across screen readers.
Include enough context in the message that it makes sense out of context. "Item added to cart" is less useful to a blind user than "Black wool scarf added to cart. Cart total: 3 items." The sighted user can see what they just clicked. The blind user is relying entirely on the message.
Do not put more than one live region with the same priority on a page. Multiple polite regions can cause announcements to step on each other. One region per page, multiple messages over time, is the cleanest pattern.

What about Shopify, WooCommerce, Squarespace, and Wix?

If you are not the developer of your own site, you may not be able to edit the HTML directly. Here is what works on each major platform.

Shopify. Most Shopify themes use the AJAX cart pattern and most of them ship without accessible toast notifications. The fix is in theme.liquid (or whatever your toast partial is called) — add an aria-live="polite" wrapper around the existing toast container. Shopify's Dawn theme (the default since 2021) ships with this set correctly in newer versions, but custom and older themes frequently do not. If you cannot edit the theme files directly, this is a 15-minute job for a freelance Shopify developer. Worth doing before any audit.

WooCommerce. The default WooCommerce "Added to cart" message is a noticeable accessibility gap that has been an open issue on the project's GitHub since 2019. Some themes patch it. Some do not. The fix lives in the theme's single-product.php or loop/add-to-cart.php template, depending on which override is in place. For a non-developer, the most practical option is to install an accessibility-focused plugin that wraps the WooCommerce notice in an aria-live region.

Squarespace. Squarespace ecommerce uses a confirmation modal rather than a toast in most templates, which is a different accessibility pattern. The modal needs to manage focus correctly (moved into the modal on open, returned to the trigger on close). Squarespace's default modal handles this reasonably well in newer templates, but custom code injection can break it. Test with VoiceOver before assuming it works.

Wix. Wix's ecommerce confirmation is similar to Squarespace's — a modal rather than a toast. Wix has improved accessibility on its Stores app in 2024–2026, but custom HTML embed widgets that you may have added do not get this treatment automatically. If you have a custom newsletter signup or contact form using Velo code, that is the place to check.

How to test in five minutes without coding

You do not need to know what aria-live is to test whether your toast notifications are accessible. Here is the five-minute test.

On a Mac, open System Settings, then Accessibility, then VoiceOver. Turn it on. (Cmd-F5 also toggles it.) Open your website. Add a product to cart, sign up for the newsletter, send a contact form message, or do whatever action your site uses toast notifications for. Listen.

If VoiceOver reads the toast message out loud, you are fine. If it stays silent, you have the failure described in this article and a 15-minute fix to schedule.

On Windows, the equivalent is NVDA, which is free. Same test: trigger the action, listen for the confirmation.

You do not need to be fluent with the screen reader to do this test. You are not navigating; you are just listening for whether the confirmation gets announced. If you can hear silence, you can run this test.

Why this matters more than it looks like it matters

It is tempting to dismiss this as a minor edge case. The toast appears, sighted users see it, blind users do not, but everything else on the site works, so what is the actual harm?

The actual harm is that the screen reader user does not know whether their action succeeded. They click Add to Cart. They do not hear anything. They cannot tell if the click registered. So they click again. Now they have two items in their cart, or three, or four, with no way to verify because the cart contents are also often delivered visually. They eventually navigate to the cart page to see what is there, discover the duplicates, and have to fix it manually.

Multiply that across every interaction on your site — every form submission, every save, every coupon application, every cart change — and you have a site that punishes screen reader users with constant uncertainty. They learn to mistrust the site. They go elsewhere. Their friends and family hear about the experience.

This is also the kind of failure that turns into ADA Title III demand letters. A plaintiff's firm runs an automated scan, finds an "add to cart" flow with no accessible confirmation, sends a demand letter, and you are in settlement negotiations over what was a two-attribute fix. The cost of the demand letter and the legal response will exceed the cost of fixing the entire site, including the toast notifications, by an order of magnitude.

And finally: this is the most fixable kind of accessibility failure that exists. There is no design tradeoff. There is no performance cost. There is no need to involve UX research. You add an attribute. The site continues to look and behave exactly as before. The screen reader user gets the confirmation. Everyone wins.

A quick mental model for the next time you ship a notification

The next time your team is shipping any feature that quietly confirms something to the user — a save, an upload, a payment, a status change — ask one question: "If the user could not see the screen, how would they know this happened?"

If the answer is "they would hear the announcement from the live region," you are doing it right. If the answer is "they would not," you have an accessibility gap.

This question scales. It applies to "saved" banners, password-strength meters, character-count indicators, loading spinners that should announce when content is ready, validation errors that appear inline, search-result-count updates that change as filters are applied, and dozens of other patterns. Every one of them is a case where sighted users get visual feedback and screen reader users get silence — unless someone built the live region.

If you take one thing from this article, take this: silence is a bug. Every confirmation that exists for sighted users should exist for screen reader users too. Live regions are how you ship that.

Color and Size Swatches: The Product Page Pattern Quietly Excluding Blind Shoppers

AgentKit — Sun, 17 May 2026 05:00:36 +0000

If your store sells anything that comes in a color or a size -- a t-shirt, a pair of sneakers, a sofa, a phone case, a candle, a bag of coffee -- there is a very good chance the product page uses what designers call "swatches." Small circles painted with each color. Small squares that say "S, M, L, XL." Tiles with a tiny photo of each finish. Visually they are wonderful. They let a sighted shopper compare options at a glance, see what is in stock, and pick a variant in one tap.

They also routinely lock out every single blind shopper who lands on the page.

Here is what we have been seeing across Shopify, WooCommerce, BigCommerce, and Squarespace storefronts in 2026: the swatch ships as a <div> with a background color. There is no accessible name. There is no role="radio" or aria-checked. There is no visible focus ring. There is no way for a screen reader to know that the user has just selected "Sapphire Blue" instead of "Charcoal Grey." The shopper hears <button> or, worse, hears nothing at all and has to guess by counting clicks. The cart accepts whatever variant happens to be selected. The order ships in the wrong color. The customer leaves a one-star review or, increasingly, files an ADA Title III demand letter.

Almost none of this shows up in a standard Lighthouse or axe scan, because a colored <div> with a click handler is technically valid HTML. The scanner has no way to know that the <div> is supposed to be a product variant control. The whole class of failure lives in a blind spot that automated tools were not built to see -- which is exactly why it has become a quiet favorite of accessibility plaintiffs' law firms scouting for clean, easily-screenshot-able violations.

What a screen reader actually hears on a typical product page

Open any storefront. Find a product with three colors and four sizes. Turn on VoiceOver (Cmd-F5 on a Mac) or NVDA (free download on Windows). Tab through the variant pickers. Here is the kind of announcement we hear over and over again across themes:

"Button. Button. Button. Button. Button. Button. Button."

Seven buttons. No names. No state. No indication of which one is the selected color, which one is the selected size, which combinations are in stock, or what happens if you pick a size that is not available in the currently selected color. A sighted user sees a row of beautiful colored circles. A blind user hears static.

Slightly better themes announce:

"Blue, button. Charcoal, button. Sand, button. Small, button. Medium, button. Large, button. X-large, button."

That is an improvement -- at least the swatch now has an accessible name -- but it is still missing three critical pieces of information:

Which variant is currently selected. A radio group of seven buttons is meaningless if the screen reader user cannot tell which one is "on."
Which combinations are out of stock. A sighted shopper sees a greyed-out swatch with a diagonal line through it. A screen reader user hears the same "button" they hear for the in-stock options.
What happens when the selection changes. When a sighted user clicks "Blue" and the price updates from $29 to $35 because Blue is the premium colorway, the screen reader user gets no announcement that the price has changed.

These three gaps are not opinions. They map to specific WCAG 2.2 Level AA criteria: 1.1.1 Non-text Content (the swatch has no text alternative), 1.4.1 Use of Color (in-stock vs out-of-stock is communicated by color alone), 4.1.2 Name, Role, Value (the selected state is not exposed programmatically), and 4.1.3 Status Messages (the price update is not announced).

Why this pattern keeps shipping

Three reasons, in roughly the order we see them on real stores:

Themes ship swatches as a visual design system, not as a component with accessibility built in. A theme author wins on screenshots, not on screen reader behavior. The Shopify theme store, the WooCommerce theme marketplace, and the Squarespace template library all reward swatches that look great in a thumbnail. The accessibility behavior is invisible in a thumbnail.

The "easy" swatch tutorials on the internet are bad. A tour of the top ten Stack Overflow answers and Shopify community posts on "how to add color swatches" returns markup using <div> and <span> with click handlers, almost never using <button> or <input type="radio">, and almost never including aria-checked or a visible focus ring. Developers copy what they find. Designers approve what they see.

Automated scans give a green light. Lighthouse, the built-in Chrome scanner, will happily report "100" on a product page where every variant control is unreadable to a screen reader, because the scanner sees <div> elements that do not violate any contrast or alt-text rule -- they are simply invisible to it as form controls.

The result is a pattern that is visible to lawyers (they screen-record a product page with VoiceOver running, paste the silent video into a demand letter, and ask for $20,000), invisible to your scanner, and present on almost every store with a theme older than two years.

What an accessible swatch actually looks like

The right pattern is well documented and not new. The W3C ARIA Authoring Practices Guide has been publishing a "radiogroup" pattern for over a decade. Here is the short version, written for someone who is going to ask their theme developer or a Shopify expert to fix it:

A variant picker is a radio group. Each swatch is a radio button. The whole group has a label ("Color" or "Size"). Each radio has a label that includes the color name or size, not just the visual cue. Exactly one radio is checked at a time, communicated via aria-checked (or, for native <input type="radio">, the checked attribute). Each radio has a visible focus ring when it receives keyboard focus -- not the browser default that the theme has stripped away with outline: none, an actual visible focus ring that meets WCAG 2.4.7 and 2.4.11.

Out-of-stock variants are marked with text, not just color. A common pattern is to render the variant with a strikethrough plus an aria-disabled="true" attribute and an aria-label like "Sand, out of stock". A user who relies on assistive technology hears "Sand, out of stock, radio button" instead of hearing the same "button" they would hear for an in-stock option.

Price updates and stock updates that happen when the user changes the selected variant are announced via a aria-live="polite" region elsewhere on the page. The user picks "Blue" and a fraction of a second later their screen reader says "Price updated to $35." The user picks "Sand" and the screen reader says "Sand, out of stock, choose a different color."

That is the entire pattern. It does not require a redesign. It does not require new graphics. It does not require a separate "accessibility mode" of the site. It requires the swatch markup to use the right elements and the right attributes, which is a one-day theme tweak for most stores.

What you can do this week, by platform

You do not need to be a developer to ship this fix -- you need to know what to ask for. Here is the minimum your store needs, in plain English, organized by platform.

Shopify. Open your theme editor and check whether your product page uses the platform's "Buttons" variant style, "Dropdowns," or "Pills/Swatches." The Dawn-family default themes (Dawn, Crave, Refresh) ship with accessible radio-group variant pickers when "Buttons" is selected, and the swatch behavior is also accessible in recent updates. If your store uses an older third-party theme (Brooklyn, Empire, Turbo, Symmetry pre-2024), you almost certainly have the broken pattern. Ask your theme developer to "convert the variant swatches to a radiogroup with proper aria-checked and a visible focus ring." Estimate: half a day to one day of developer time. If you do not have a developer, the Shopify Experts directory will quote this fix at $200-$500 for most themes.

WooCommerce. The default WooCommerce variation dropdown is technically accessible -- a real <select> element with <option> children works correctly with every screen reader. The accessibility breaks when a "swatches plugin" replaces the dropdown with a custom UI. The most common offenders are early versions of Variation Swatches for WooCommerce and several abandoned plugins; the current top plugins in this category have improved meaningfully but still ship configurations that drop the focus ring or omit the selected-state attribute. Test your specific configuration with the keyboard (Tab to the swatch group, arrow keys between options, Space to select) and with a screen reader before you assume your plugin handles this correctly.

BigCommerce and Squarespace. Both platforms have native variant pickers that ship reasonably accessibly when used as designed. The failures here almost always come from custom code or third-party apps that override the default variant UI. If your store has custom variant tiles, treat them the same way you would a custom Shopify theme: get the markup audited.

Custom-built stores (Next.js, Astro, Remix, Rails). This is where the broken <div> pattern is most common, because the developer wrote the variant picker from scratch and did not pull in a tested radio-group component. Ship one of the open-source headless components (Radix UI's RadioGroup, React Aria's useRadioGroup, Headless UI's RadioGroup) or rebuild the pattern by hand from the ARIA Authoring Practices Guide. Every team that has done this in production has come back to us and said the same thing: it took a single developer between half a day and a day, and the resulting component is more usable for everyone, including sighted shoppers on mobile who now have a focus ring they can see and a tap target that meets WCAG 2.5.8.

The conversion case

We have looked at enough storefronts now to say with confidence that this is not just an accessibility story -- it is a conversion story. Every time we audit a product page with broken swatches, we find:

Mobile shoppers tapping the wrong variant because the target is too small and there is no visible feedback when the swatch is selected (WCAG 2.5.8 target size, 2.4.11 focus appearance).
Customers ordering the wrong color and contacting support to return the item, which costs the merchant the shipping label both ways plus the staff time.
Repeat customers who used to rely on a built-in browser autofill assistant or a third-party tool (extensions for low-vision users, screen magnifiers, switch control on iOS) who quietly stopped coming back after a theme update broke the variant picker for them.

You will not see any of this in your analytics, because the customers who hit it do not file a support ticket -- they just leave. The shape of the lost revenue is invisible until you instrument for it, which most stores do not.

The legal case

Plaintiff law firms specializing in ADA Title III digital accessibility complaints are now routinely scanning product pages for exactly this pattern, because the screenshots and the screen recordings make a clean case. A demand letter that includes a 20-second video of VoiceOver saying "button, button, button, button" over a row of beautiful colored swatches is the kind of evidence that settles for $5,000 to $25,000 in the United States and that, after June 28, 2025, can also trigger enforcement under the European Accessibility Act for any product sold to consumers in the EU. None of this is legal advice, and you should consult a qualified attorney for your jurisdiction, but the pattern is real and the trend is up.

What to do in the next 30 minutes

You can audit your own store right now, no tools required. Open a product page. Use only your keyboard -- no mouse, no trackpad. Tab to the variant pickers. Try to select a different color. Try to select a different size. Try to add the result to your cart. Did your keyboard focus ring stay visible the whole time? Did the swatch you selected look different from the others, in a way that does not depend only on color? Did the "Add to Cart" button update to reflect your new selection?

Then open VoiceOver (Cmd-F5 on Mac) or NVDA (free at nvaccess.org). Navigate the same page with your eyes closed. If you cannot tell which color is currently selected, which size is currently selected, or whether your chosen combination is in stock -- that is the bug. Take a 30-second screen recording. Send it to your theme developer with one sentence: "Please convert this variant picker to a proper accessible radio group." It is the highest-leverage single fix most product pages can ship this quarter.

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

When Your Chat Bubble Hides Form Errors: The Accessibility Bug Behind Mystery Sign-Up Drop-Offs

AgentKit — Sat, 16 May 2026 05:00:38 +0000

Picture the moment a person fills in a sign-up form on your website, taps the submit button, and nothing visibly happens. The form does not advance. There is no success message. There is no obvious error. The visitor stares at the page for a few seconds, scrolls a little, then leaves. Your analytics record it as a drop-off; your sales team calls it a low-intent visitor; your developer says the form is working fine and demonstrates it by submitting a test entry from their desk.

The form is working fine. The bug is that your live-chat bubble — Intercom, Drift, Zendesk Messaging, HubSpot Live Chat, Tidio, Crisp, Tawk.to, LiveChat, Olark, Front, or whichever vendor sits in the bottom-right of every page — is physically covering the validation error that the form is showing. The visitor's submit attempt did produce an error message like "Please enter a valid email address" or "We could not process your payment." That message is rendered underneath a 60 by 60 pixel chat widget pinned to the lower-right corner of the viewport, on a phone or a small laptop where the form itself is pushed close to the chat bubble, and the visitor never sees it.

This is a single, specific, common bug. It is also an accessibility failure under WCAG 2.1 Success Criterion 1.4.10 Reflow and Success Criterion 1.4.13 Content on Hover or Focus, and it has begun to show up in ADA demand letters as plaintiffs' firms get more sophisticated about live-chat widget patterns. This article walks through what is happening, why the bug is so easy to ship, why it matters legally and commercially, how to test for it in five minutes without any developer tooling, and how to fix it without rebuilding your site. None of this is legal advice; consult a qualified attorney for your jurisdiction.

The exact failure mode in plain English

Modern websites typically place form error messages directly below the field that has the problem, or directly above the submit button, in a small block of red or orange text. Designers like this pattern because the eye returns to where it was just looking. On a desktop monitor at full width, the form field, the error, the submit button, and the chat bubble all have plenty of room and never overlap.

Then a real visitor opens the page on a phone or a 13-inch laptop with a browser zoom level above 100%. The form fields stack vertically, the page is now narrow, and the submit button sits maybe 80 pixels above the bottom edge of the viewport. The error message that appears below the submit button — or the success message, or a "we will email you shortly" confirmation — falls into that 80-pixel zone. The chat bubble, which is fixed to the bottom-right corner with position: fixed in CSS and is roughly 60 by 60 pixels, sits squarely on top of it.

The visitor cannot see the error. There is no obvious indication that the form was rejected. The chat bubble itself does not announce that it is covering anything. A sighted user with full vision may notice that the bubble is in the way and scroll the form upward; a person browsing with one hand on a phone, or with low vision and a 200% zoom level, or with motor impairments that make scrolling difficult, may not.

The same failure happens with the chat-widget greeting balloon — the larger "Hi, can I help?" speech-bubble that pops out from above the chat icon thirty seconds after the page loads. That balloon can be 300 pixels tall and frequently obscures the entire footer of a sign-up form on a small viewport.

Why this counts as a WCAG failure

Two specific WCAG 2.1 success criteria are implicated, and a third one from WCAG 2.2 adds further exposure.

WCAG 1.4.10 Reflow (Level AA) requires that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a viewport width equivalent to 320 CSS pixels. When the chat bubble covers a critical form error at a 320-pixel viewport — which is roughly the width of a phone in portrait mode at 200% zoom — the page has lost critical information. Plaintiffs' counsel and DOJ-style investigators look at 1.4.10 as a meaningful conformance gap because reflow failures are objective and measurable: open the page at the specified viewport, photograph the result, and the covered content is either visible or it is not.

WCAG 1.4.13 Content on Hover or Focus (Level AA) requires that additional content triggered by hover or focus — exactly what the chat-widget greeting balloon does — must be dismissable (the user must be able to close it without moving pointer focus), hoverable (the user must be able to move the pointer to it without dismissing it), and persistent (it must remain visible until the user moves focus away). A greeting balloon that auto-appears and covers a form error fails the dismissable requirement on most widgets, because closing the balloon requires clicking the chat-bubble icon precisely on its small "x" target — which may itself be hidden by the obscured form content.

WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA) is a fresh addition that explicitly requires that when an interactive element receives keyboard focus, that element is not entirely covered by author-created content. A keyboard-only user who tabs to the submit button and then sees nothing visibly change because the chat bubble covers the post-submit error has hit a 2.4.11 failure directly. EU member states implementing the European Accessibility Act treat WCAG 2.2 as the operational reference for digital-services conformance in 2026, so 2.4.11 is now a live obligation for any operator selling into the EU.

The combination of these three criteria means a chat widget covering form errors is not a borderline edge case. It is a stack of named, documented conformance failures, each one independently actionable.

Why the legal exposure is real, not theoretical

Three patterns are pushing chat-widget accessibility failures into demand-letter inboxes.

First, plaintiffs' firms have moved past the easy targets of missing alt text and unlabeled buttons. The 2025–2026 generation of ADA demand letters cites specific WCAG criteria with screenshots. We have seen letters in the past six months that quote 1.4.10 directly, attach a 320-pixel-wide screenshot of the operator's contact page, and identify the live-chat widget by vendor name and the obscured content beneath it. The legal theory is that the operator deployed a third-party widget knowing — or with reckless disregard — that it would interfere with form submissions, which is a barrier to access. Settlements in the $5,000 to $25,000 range plus remediation costs are typical for small operators; larger sites see proportionally larger numbers.

Second, the European Accessibility Act took effect on June 28, 2025, and the first wave of EAA enforcement actions in 2026 has focused on consumer-facing e-commerce flows where the visible defect is unambiguous and the regulator can show harm with a single screenshot. Chat widgets covering checkout-form errors are exactly the kind of clear, photographable failure that EU consumer-protection authorities prioritize for enforcement.

Third, state attorneys general in California, New York, Massachusetts, and Washington have been investigating chat widgets as separate from the website-platform-and-developer chain. Vendor agreements, the operator's responsibility for the widget configuration, and whether the operator disclosed the third-party widget in its accessibility statement are all open questions. Operators who deployed the widget with default settings and never tested its impact on the rest of the page are particularly exposed.

How to test for the bug in five minutes

You can test for this bug yourself, with no developer tools and no accessibility audit software, on any laptop or desktop with a recent web browser.

Step one — open the page that hosts the form you most care about. Sign-up, contact, checkout, lead-capture, or appointment-booking forms are the highest priorities.

Step two — resize the browser window to roughly 320 pixels wide (about a third of a standard laptop screen). In Chrome, Edge, or Firefox you can also press F12 to open developer tools, click the device-toolbar icon, and select "iPhone SE" or any small phone profile.

Step three — submit the form with deliberately wrong data. Enter an obviously invalid email like "notarealemail" or leave a required field blank. Submit.

Step four — look at where the error message appears, and ask: is any part of it covered by the chat-widget icon or its greeting balloon? Take a screenshot with the chat bubble visible.

Step five — repeat with the form submitted correctly, and check whether the success message ("Thanks, we will email you shortly") is also covered.

If either is covered, you have a confirmed bug, and your audit trail is now a single screenshot.

For a deeper test, use the browser's built-in zoom (Ctrl-Plus on Windows or Cmd-Plus on Mac) to raise the page to 200% zoom at a standard laptop width, then repeat the form-submission test. This simulates the experience of a visitor with low vision who has set their browser to default-zoom 200%, which is increasingly common.

How to fix it without rebuilding the page

Five fixes, in roughly increasing order of effort. Pick the first one that fits your stack.

Move form errors above the submit button instead of below. This is the simplest and most universally applicable change. Most form-validation libraries can be configured to render errors above the input field they belong to, or directly above the submit button at the top of the form. Errors at the top of the form are nowhere near the chat bubble at the bottom. They are also better for screen-reader users because the screen reader will encounter them earlier in tab order.

Render an inline accessibility-friendly error summary at the top of the form on submit. When the form validation fails, programmatically render a summary block at the top of the form ("Three problems prevented your sign-up:") with a list of the specific errors, each one a link to the field that has the problem. Move keyboard focus to that summary block on submit. This pattern is well-supported by every major front-end framework and works with any chat-widget vendor because the summary is at the top of the form, far from the bottom-right corner.

Reposition the chat bubble in CSS so it does not overlap the form viewport area. Every major chat-widget vendor (Intercom, Drift, Zendesk, HubSpot, Tidio, Crisp, Tawk.to, LiveChat, Olark) provides a configuration option to set the launcher position. Move it to the bottom-left, give it more vertical offset from the bottom edge, or hide it entirely on the specific pages that contain critical forms (sign-up, checkout, contact). On checkout pages many e-commerce operators hide the chat launcher entirely because the chat is not part of the checkout flow and tends to compete for attention with payment fields.

Suppress the greeting balloon on form pages. The auto-appearing "Hi, can I help?" balloon is configured separately from the chat-bubble launcher in every major vendor. Disable it on sign-up, checkout, and high-stakes form pages. Keep it on marketing and product pages where it does not interfere with form errors.

Make the chat-widget dismiss state persistent. When a visitor dismisses the chat bubble or greeting balloon, store the dismissal in local storage so it does not re-appear on the next page load in the same session. Most vendors support this with a single configuration flag and it dramatically reduces the chance that a visitor who cleared the chat bubble on the home page will see it re-appear and cover errors on the checkout page.

For mobile-specifically, several vendors now support a "hide on mobile" toggle that removes the launcher on viewports below a configured width. If your form drop-off is concentrated in mobile traffic, this single setting may resolve the bug for the majority of affected visitors.

After the fix, re-run the five-minute test above. Verify that the error and success messages are now fully visible at the 320-pixel viewport, at 200% browser zoom, and at the most popular mobile viewport sizes your analytics show.

What this means for your accessibility statement

If your site has a published accessibility statement — and operators selling into the EU under the EAA now generally need one — your chat-widget configuration is part of the conformance picture. Two practical implications.

First, name the specific live-chat or messaging vendor by product name in the third-party-services section of your accessibility statement. Acknowledge that the widget is configured on the site and describe how the operator has worked with the vendor to address accessibility issues. Generic language about "we use third-party services" is not enough; named-vendor disclosure is increasingly the regulator and plaintiff-counsel expectation.

Second, document your decision in writing. If you have chosen to disable the chat widget on certain pages, hide the greeting balloon, or move the launcher position, write down what you chose and why. Keep that document with the rest of your accessibility audit trail. When a demand letter arrives, the operator with a written accessibility decision record is in a substantially better position than the one without.

A note on AI chatbot replacements for live chat

Several operators have moved from a human-staffed live chat to an AI chatbot that presents itself as live chat. The accessibility issues described above all still apply: the launcher position, the greeting balloon, and the obscured form errors. The AI chatbot adds an additional layer because the chatbot's own response messages must themselves meet WCAG 2.1 AA on text contrast, focus management, and screen-reader support. If you have switched from a human team to an AI chatbot in the past twelve months, treat that as a reason to re-test the chat widget's interaction with the rest of the page, not as a reason to assume the accessibility profile is unchanged.

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

Global Accessibility Awareness Day 2026: A Small-Business Action Plan for the Week Leading Up to May 21

AgentKit — Fri, 15 May 2026 05:00:39 +0000

Global Accessibility Awareness Day is on May 21 this year. It is the third Thursday in May, the way it always has been since 2012, and it is the one day a year when the entire web -- developers, designers, regulators, journalists, even the people at the platforms you depend on -- pays attention to whether websites work for people with disabilities.

For a small-business owner, GAAD is awkward. The big tech companies post their accessibility highlight reels. Government agencies announce new compliance deadlines. The big agencies publish their pricey audit packages. And you, the person running a five-person business with one part-time web person, are left wondering whether you are supposed to do something, and if so, what.

Here is what you are supposed to do: something. Anything. The goal is not to fix everything before May 21. The goal is to use the week as a focusing event -- a reason to spend a few hours on a topic you have been deferring all year. By May 21 you should be able to point at one concrete thing that is better than it was on May 15.

This is a six-day plan that gets you there. Each day is roughly thirty to sixty minutes of work, no developer required, no money spent. By Thursday you will have done more than ninety percent of small businesses do in an entire year.

Why bother if nobody is going to sue you next week

The honest answer is: somebody might. The ADA Title III plaintiffs' bar has been filing roughly 4,500 website-accessibility lawsuits per year in U.S. federal and state courts for the last three years, and the rate has accelerated in 2026 since the Department of Justice published its Title II final rule and signaled that WCAG 2.2 AA is the new floor. Small businesses are not exempt. The plaintiffs' firms specifically target small businesses because the settlement math is favorable for them: a small business is more likely to settle for $8,000–$15,000 to make the case go away than to litigate for $200,000.

But the real reason to bother is more boring than that. Fifteen to twenty percent of every human population has a disability. If your website does not work for them, you are leaving fifteen to twenty percent of your potential customers on the table. The accessibility-aware customers also tell their friends, leave better reviews, and -- this is the part the SEO community has finally figured out -- spend longer on accessible pages, which Google reads as a quality signal. Accessibility is not just about compliance. It is about whether the customers you already paid to acquire can actually buy from you.

GAAD is just an excuse to start.

Day 1 (Friday, May 15): Take the keyboard test

Open your homepage in any browser. Put your mouse on the other side of the desk. Press the Tab key.

A focus indicator -- usually a thin outline around the currently selected element -- should jump from one interactive thing to the next: the menu, the search box, each navigation link, each button, each form field. Keep pressing Tab and try to get from the top of the homepage all the way to the footer using only the keyboard.

Three questions to answer:

Can you see the focus indicator at every step? If at any point the focus indicator disappears entirely -- you can no longer tell what is selected -- that is a WCAG 2.4.7 (Focus Visible) failure. This is the single most common issue on small-business websites and it is fixable in about ten minutes by anyone who can edit a stylesheet.

Does the tab order make sense? It should follow the visual order, roughly top-to-bottom, left-to-right. If Tab jumps from the header to the footer and then back up to the middle of the page, that is a WCAG 2.4.3 (Focus Order) failure and your customers using screen readers are getting a scrambled experience.

Can you actually complete the things your customers need to do? Try to add an item to your cart with the keyboard. Try to submit your contact form. Try to use your search box. If any of these traps you -- you can tab in but not out, or you cannot reach the submit button at all -- that is a WCAG 2.1.2 (No Keyboard Trap) or 2.1.1 (Keyboard) failure.

Write down what you find. Do not fix anything yet. Today is a diagnostic, not a fix.

Day 2 (Saturday, May 16): Run a free automated scan

Visit wave.webaim.org/ and enter your homepage URL. Wave is a free tool from WebAIM that flags the most obvious accessibility issues automatically.

You will get a list. Some entries will be red ("errors") and some will be orange ("alerts"). Ignore the alerts for now -- those are things that might be a problem but require human judgment. The red ones are the ones to focus on.

The three most common red errors on small-business sites are:

Missing alt text on images. Wave flags every image that has no alt attribute. For decorative images (background photos, logos, icons that have text next to them) the fix is to add alt="" -- an empty alt attribute, not no alt attribute. For meaningful images (product photos, blog header images, screenshots) the fix is to write a one-sentence description of what the image shows. Our alt text guide walks through the difference.

Missing form labels. Wave flags every form field that does not have a label. The fix is to add a <label for="email">Email address</label> element next to the input. If you cannot edit HTML directly, your platform -- Squarespace, Wix, Shopify, WordPress with a page builder -- has a way to set labels on form blocks. Most platforms get this right by default; most third-party widgets (Mailchimp, ConvertKit, HubSpot embeds) get it wrong, which is why we keep flagging them.

Empty links and buttons. Wave flags links that have no text and buttons that have no label. The most common cause is a social-media icon link that has an image but no aria-label="Facebook" to tell a screen reader what the icon is for. The fix is one attribute per icon.

Scan your homepage, your most-trafficked landing page, and your contact page. Note the count of red errors on each. By the end of the week you want that count to be lower than it is today.

Day 3 (Sunday, May 17): Check your color contrast

Visit webaim.org/resources/contrastchecker/. This is a free contrast checker, also from WebAIM.

For your site's three most important text combinations -- body text on background, link text on background, button text on button -- get the hex codes of the foreground and background, plug them in, and look at the result.

WCAG 2.1 AA requires a contrast ratio of at least 4.5 to 1 for body text and 3 to 1 for large text (18 point or 14 point bold). If your body text is light gray on white, your link text is brand-blue on white, or your call-to-action button has white text on a pastel background, you are likely failing.

The fix is usually trivial: darken the body text, darken the link color, change the button background to something closer to your brand's primary color. The reason this is worth doing is that low-contrast text is one of the most-tested accessibility issues by plaintiffs' firms -- because it is one of the easiest things to prove in a complaint. Our color contrast guide explains the math and walks through the most common small-business failures.

Make a list of every text/background combination that fails. Adjust your site's primary brand colors if needed. This is a thirty-minute task that often pays back in a 5–10% boost in conversion, because the text that was illegible to your low-vision customers is now legible to all your customers.

Day 4 (Monday, May 18): Fix the top five issues

You now have three lists: keyboard issues from Day 1, automated-scan issues from Day 2, and contrast issues from Day 3.

Pick the top five things across all three lists. Fix them.

For most small businesses, the top five will be:

Add a visible focus indicator to your CSS (one or two lines: :focus { outline: 2px solid #1a1a1a; outline-offset: 2px; })
Add alt="" to every decorative image and write real alt text for every meaningful image
Add <label> elements (or platform-equivalent labels) to your contact form, your newsletter signup, and your search box
Add aria-label attributes to your social-media icon links and any other icon-only buttons
Bump your body-text color from #888 (or whatever low-contrast gray you are using) to #333 or #000

If you cannot fix something yourself, write it down for your developer or your platform's support team. Send the list. Do not wait until June.

Day 5 (Tuesday, May 19): Write or update your accessibility statement

An accessibility statement is a public page on your website that says three things: (1) you are working on accessibility, (2) this is the standard you are working toward (usually WCAG 2.1 AA or WCAG 2.2 AA), (3) here is how to contact someone if you find an accessibility problem.

This is the single most-leveraged thirty minutes you will spend this week. An accessibility statement is not legally required everywhere, but in jurisdictions where it is recommended (most EU member states under the EAA, several U.S. states for public-accommodation websites), having one demonstrably reduces lawsuit risk because it shows good-faith effort and gives a customer with an accessibility complaint a path other than calling a lawyer.

Our accessibility statement guide has a template you can adapt. The minimum version is four paragraphs and a contact email. Publish it at /accessibility/ or /accessibility-statement/, link to it from your footer, and add the date you last updated it.

Day 6 (Wednesday, May 20): Tell someone

This is the part most small-business owners skip, and it is the part that matters most.

Pick one person on your team -- a designer, a copywriter, a customer-support lead, your virtual assistant -- and tell them what you did this week. Walk them through the list. Show them the keyboard test. Show them the contrast checker. Show them the WAVE scan.

The goal is not to make them an accessibility expert. The goal is to make sure that the next time someone on your team launches a new page, embeds a new widget, swaps a brand color, or changes the footer, they know that accessibility is a thing they should be checking. One person who knows this is far more valuable than one expensive audit you commission once a year and then forget about.

If you have an external developer, send them the WAVE report and ask them to flag accessibility issues in their pull requests from now on. If you use a page-builder platform, look at their accessibility documentation and bookmark it. If you have a design system or brand-style guide, add a contrast-ratio requirement to it.

This is what makes GAAD work for a small business: not the heroic one-time push, but the small handoff that makes accessibility somebody's job going forward.

What to do on May 21

On the actual day, do three things.

First, run the WAVE scan again on your homepage. Compare the error count to the one you wrote down on Day 2. It should be lower. That is your GAAD result. Take a screenshot.

Second, post about it -- on LinkedIn, on your blog, in your newsletter, wherever your customers see you. You do not need to be technical. "We took accessibility seriously this week and made these five fixes to our website" is enough. Customers with disabilities and their families notice this. So do regulators and journalists who cover the space.

Third, put May 19, 2027 on your calendar as the start of your GAAD 2027 prep week. Make it a yearly habit.

That is the entire plan. Six days, no money, no developer required, and at the end of it your website is measurably more accessible than it was a week earlier. The plaintiffs' bar can still file a lawsuit against you next month, but you will be in a much stronger defensive position than the ninety percent of small businesses that did nothing this week. And -- the part that actually matters -- a few more of your customers can buy from you than could last Friday.

Your Site Probably Blocks Pinch-to-Zoom on Mobile. That Is a Lawsuit Risk.

AgentKit — Thu, 14 May 2026 05:00:44 +0000

Open your website on a phone right now. Take two fingers and try to pinch-to-zoom on the body text. If the page resists, snaps back, or simply ignores you, your site has a problem that almost every accessibility consultant flags inside the first ten minutes of an audit. It is one of the easiest accessibility failures to ship by accident and one of the easiest to fix once a developer looks at it. It is also one of the failures that turns up most often in demand letters from US plaintiffs' firms in 2026, because every iPhone and Android device since 2018 makes it trivial for a customer to demonstrate the issue on video.

This article is written for non-developers -- founders, marketing managers, ecommerce owners, in-house counsel reviewing an audit report. You do not need to read HTML to act on any of this. You need to understand what the bug is, why it matters legally, how to confirm whether your own site has it, and exactly what to ask your developer to change.

What is actually broken

Every modern website has a tiny piece of HTML in its head section called the viewport meta tag. It tells the phone browser how to size and scale the page. Most websites copied a version of it from a Stack Overflow post or a starter template years ago. A surprisingly large fraction of those starter templates contain two short instructions that, taken together, prevent the user from zooming the page: maximum-scale=1.0 and user-scalable=no.

The reason developers used those instructions historically was vanity. In the early days of responsive design, some developers were worried that users would accidentally zoom and ruin their carefully crafted layouts. Apple and Google have both said, in their developer documentation and in their accessibility guidelines, that disabling user zoom is almost always wrong. But the bad copy-paste lives on. The WebAIM Million report has consistently found that roughly one in three home pages of the top million sites still ships with user-scalable disabled in 2026, even after a decade of public guidance against it.

The result is that a customer with low vision who needs to zoom a phone screen to 200 percent or 300 percent to read your text simply cannot. They can pinch and pull at the screen, and the browser snaps it back to the original size. They cannot read your menu, they cannot fill in your form, they cannot complete their order. They give up and go somewhere else. Sometimes they file a complaint.

The Web Content Accessibility Guidelines criterion this fails

The bug fails two specific WCAG success criteria. The first is 1.4.4 Resize Text at Level AA, which requires that text can be resized up to 200 percent without loss of content or functionality. The second is 1.4.10 Reflow, also Level AA, which requires that content can reflow at 320 CSS pixels wide and a 400 percent zoom on desktop. On mobile, the practical equivalent is that pinch-to-zoom must work.

WCAG Level AA is the standard that every major accessibility law in 2026 points to. The US Department of Justice Title II rule that became enforceable in April 2026 references WCAG 2.1 AA. The European Accessibility Act, in force since June 2025, points to WCAG 2.1 AA through the harmonised standard EN 301 549. The UK Public Sector Bodies Accessibility Regulations, the Section 508 update for US federal contractors, AODA in Ontario, and the Australian Disability Discrimination Act case law all converge on the same baseline.

Failing 1.4.4 and 1.4.10 means your site fails the law in every one of those jurisdictions. None of this is legal advice -- consult a qualified attorney for your jurisdiction -- but the pattern in 2026 demand letters is consistent: plaintiffs' firms include a screenshot of your site, a screenshot of the viewport tag with user-scalable=no highlighted, and a short paragraph explaining the WCAG criterion. It is a copy-paste accessibility violation, which is exactly why it is so common in copy-paste demand letters.

How to check your own site in two minutes

There are three quick ways. None of them require developer tools.

First, the gesture test. Open your site on an iPhone or Android phone. Try to pinch-to-zoom on a paragraph of body text. If the page resists, snaps back, or refuses to scale, your site has the bug. Try a few different pages. Sometimes the home page is fine but the checkout page is broken, because the checkout was built later by a different developer with a different template.

Second, the iOS Accessibility Inspector test. On an iPhone, open Settings, then Accessibility, then Zoom, and turn Zoom on. Open your site. Try to zoom the rendered page. iOS will sometimes still let users zoom even when a site has disabled it, depending on the version, so this test is less reliable than the gesture test. It is a good sanity check for the worst cases.

Third, the source-code test. In Chrome or Edge on a desktop computer, open your site. Right-click anywhere on the page and choose View Page Source. In the long block of HTML that opens, press Ctrl-F (or Cmd-F on a Mac) and search for the word "viewport." You will land on a line that looks something like this:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

If you see maximum-scale=1.0 or user-scalable=no (or both), your site has the bug. The correct version of the line is shorter:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

You do not need to memorise the syntax. You need to be able to spot the offending words and point at them. That is enough to start a useful conversation with whoever maintains your site.

What an actual demand letter looks like

The pattern in 2026 looks like this. A plaintiff's firm trains a paralegal to scan the websites of small businesses in a target industry -- often hospitality, professional services, ecommerce, or healthcare -- with a checklist. The paralegal runs an automated scan, captures the viewport tag, records a short video on a phone trying to zoom, and sends a demand letter offering to settle for a fixed fee (commonly between 10,000 and 25,000 US dollars depending on jurisdiction).

The letter rarely names every accessibility issue on the site. The viewport bug appears in nearly all of them, because it is so easy to demonstrate. The letter cites WCAG 1.4.4 and 1.4.10, points at the line of HTML, and includes the screenshot. The settlement offer is structured to be lower than the cost of defending the case, which is the entire point of the model. Most small businesses pay.

Three things matter for prevention. First, do not ship the offending viewport tag in the first place. Second, run your published accessibility statement carefully, because a site that publishes a statement claiming WCAG 2.1 AA conformance while failing 1.4.4 is at higher risk of an unfair-practices claim than a site that quietly fails. Third, document a remediation backlog with dates, because demand-letter triage in 2026 increasingly responds to evidence of active remediation work.

What to ask your developer to do

The fix takes about three minutes for a competent developer in any modern stack. You will be asked one question in return: do you want pinch-to-zoom enabled on every page, or do you have a specific page (a 3D product configurator, a custom drawing tool, a kiosk-mode page) where disabled zoom is intentional? In practice the answer is almost always "every page."

The specific instruction to give your developer is short. Open the relevant template -- in WordPress this is usually header.php; in Shopify it is the theme.liquid file; in Squarespace and Wix it is a single setting in the custom-header advanced section; in React, Vue, Angular, or other JavaScript stacks it is in the application shell. Replace the existing viewport meta tag with this exact line:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Do not include maximum-scale and do not include user-scalable. That is the whole change.

After the fix is shipped, repeat the gesture test on the live site to confirm. Then add the test to your release checklist so that the bug does not come back the next time a new template is installed or a junior developer copies the wrong starter project.

Common objections, briefly answered

"But our designer prefers the locked-down look." That is a design preference; WCAG conformance is a legal requirement. The two conflict here, and the legal requirement wins. A designer who cannot accommodate user zoom in 2026 needs to update their training.

"Our analytics show very few users zoom." This is sometimes true and almost always misleading. Many low-vision users have already left your site because they could not use it; they do not appear in your analytics. WebAIM survey data has consistently found that customers with low vision are roughly proportional to the general population (around 7 percent of adults have a moderate or worse vision impairment), but their representation in your data is suppressed by the very bug you are measuring.

"We have a custom mobile app and we disabled zoom there." That is a separate question with separate WCAG criteria. Native mobile apps fall under WCAG 2.1 AA via different mechanisms (and Section 508 references them explicitly), so the same logic broadly applies. Native app text scaling is usually handled by following the operating system's dynamic type or accessibility-text-size settings rather than by pinch-to-zoom. Consult your mobile-app developer separately about that.

"We tried to enable zoom and it broke our layout." That is a design problem, not a zoom problem. Modern responsive layouts handle zoom gracefully. If yours does not, your layout has a deeper issue that will also fail WCAG 1.4.10 Reflow on desktop. Fixing the viewport tag is step one; fixing the layout to handle scaling without horizontal scroll or content clipping is step two.

Why this is worth doing this week

The barrier between "this is broken" and "this is fixed" is one line of HTML. The barrier between "we did not know" and "we did know and ignored it" is reading this article. The barrier between "we settled a demand letter for 18,000 dollars" and "we did not get a demand letter in the first place" is usually a remediation backlog that includes the line item "fix the viewport meta tag, sitewide."

For the cost of one short conversation with your developer, you remove one of the most common entries on a 2026 demand-letter checklist. There are dozens of other accessibility issues to fix on most sites, but this is the cheapest, fastest, and most legally exposed one. Start here.

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

Online Course Accessibility: A Non-Developer's Guide to Teachable, Kajabi, and Thinkific

AgentKit — Wed, 13 May 2026 05:00:49 +0000

If you sell online courses, the first thing that usually surprises you is how much accessibility responsibility still belongs to you after you have chosen a platform. Teachable, Kajabi, Thinkific, Podia, LearnWorlds, and Mighty Networks all market themselves as production-ready. They are, for the parts they control. But the parts you upload -- your video lessons, your PDF worksheets, your sales pages, your email funnels -- are yours. And those are the parts that draw demand letters.

This guide is written for creators, not developers. If you can edit a sales page, upload a video, and paste a link into an email, you can do every fix in this article.

Why this matters more than you probably think

Course creators tend to assume that accessibility complaints target big e-commerce stores and government sites. That is no longer true. Over the past eighteen months, plaintiffs' firms in California, New York, and Florida have expanded demand-letter campaigns into online education. The targets are solo creators running six- and seven-figure course businesses on hosted platforms, not just large edtech companies.

There are three reasons the sector is getting attention. First, course sales pages tend to be long, image-heavy, and video-dependent -- a combination that produces obvious accessibility failures. Second, the transactional flow is clear: the plaintiff attempted to enroll, could not, and has damages. Third, the European Accessibility Act now covers consumer-facing education services for EU residents, which means even a U.S.-based creator with a handful of EU students may be in scope.

The good news is that most of the fixes are cheap. You do not need to migrate platforms or hire a developer. You need to check a list of specific things, most of which you already know how to change.

What your platform actually handles

Let's be fair to the platforms. Modern course-hosting tools do get some accessibility basics right out of the box. Teachable, Kajabi, and Thinkific all ship with:

Keyboard-accessible navigation on their default themes
Reasonable color contrast in most theme presets
Alt-text fields on image uploads (though they don't force you to fill them)
Captions support on video players (though the captions themselves are yours to provide)
Accessible form controls on checkout and signup pages

That gets you maybe sixty percent of the way there. The remaining forty percent is the material you upload. Let's work through it.

The five things that are actually your responsibility

1. Video captions -- real ones, not auto-generated

This is the single biggest accessibility failure in online courses. Every platform will happily let you upload a video and play it with no captions. Many creators rely on auto-generated YouTube or Vimeo captions and assume that meets the standard. It does not.

WCAG 2.2 requires captions for all prerecorded video content. The caption track must be accurate -- that is, correct words in the right sequence, with speaker identification when more than one person is speaking, and with relevant non-speech sounds noted. Auto-captions routinely get technical terms wrong, miss speaker changes, and drop whole phrases. If your course uses industry jargon, your auto-captions are almost certainly inaccurate enough to fail an audit.

The fix is straightforward. Upload your video to Descript, Rev, or a similar service, clean up the auto-generated transcript (it takes about two minutes per minute of video), and export a .srt or .vtt caption file. Upload that file alongside your video in your course platform's video manager.

For longer courses, batch this work. Process all your existing videos in a single afternoon; then make "export cleaned captions" part of your post-production checklist for new videos. If you need help with the details, our video accessibility and captions guide walks through the process step by step.

2. Transcripts for audio-only content

If your course includes audio recordings -- podcast-style interviews, guided meditations, pronunciation drills -- you need a text transcript. The same services that clean up your captions will produce a transcript as a side effect. Paste the transcript into a text lesson below the audio player, or attach it as a downloadable file.

If you are selling a course that is heavily audio-based and has no transcripts, a deaf-blind student using a refreshable braille display literally cannot take your course. That is the scenario an audit report will describe, and it is an easy one to fix.

3. PDFs that are actually readable

Course creators love PDFs. Workbooks, printable checklists, recipe cards, worksheets. The problem is that most course PDFs are exported from Canva, Keynote, or a Word document and then never opened in Acrobat. The result is a file that screen readers either cannot read at all or read in the wrong order.

There are three quick checks you can do on any PDF you sell.

First, can you select text with your mouse? If the PDF is an image (your selection tool does nothing), it is not accessible. Re-export from the source document, not a screenshot.

Second, can you tab through form fields? If your worksheet has fillable fields, tab order matters. In Acrobat Pro (or free alternatives like Sejda), you can set the tab order explicitly.

Third, does the PDF have alt text on its images? Most Canva exports do not. Canva added alt-text support in late 2024; double-check each image before you export. If you are stuck with PDFs you cannot fix, our accessible PDF guide walks through remediation.

A reasonable target: if a student cannot read your workbook with a screen reader, the workbook is not compliant, no matter how pretty it looks.

4. Sales pages that work without vision

Sales pages for online courses are usually long-scroll Kajabi or Teachable pages with testimonials, hero videos, bullet lists of benefits, and a big buy button at the bottom. The accessibility problems are usually in four places.

Hero video. If autoplay is on and there is audio, that is a WCAG 1.4.2 failure. Turn off autoplay, or keep autoplay on but mute the audio by default with a visible play button.

Testimonial images. Photos of students with the quote rendered as text on the image are inaccessible by default. The quote should be real HTML text, with the photo as a separate image with meaningful alt text ("Maria, who lost twenty pounds in three months").

Icon-only feature lists. Many themes render benefits as an icon next to a short label. The icon is usually decorative, which is fine, but the label must be real text. Check by turning off images in your browser -- can you still read the page?

The buy button. The single most important element on the page. It should be a real button with descriptive text ("Buy the Full Course for $497") rather than a button that says "Click here" or, worse, an image styled as a button. Click it with your keyboard Tab key. It should work.

5. Checkout and onboarding emails

After the purchase, your course platform sends a series of emails: welcome, login details, first-lesson reminder. These are often edited by the creator to match their brand voice, and in the editing they frequently break accessibility.

Three things to watch. First, if you paste images into your emails (course thumbnails, welcome banners), each image needs alt text. Most email editors have an alt-text field; use it. Second, if you embed colored call-to-action buttons, use the email editor's button component rather than an image of a button -- that way the text inside the button is real text. Third, avoid long links as anchor text ("https://learn.example.com/p/my-course/lessons/1"); replace them with descriptive text ("Start your first lesson").

The same principles apply to abandoned-cart sequences and drip funnels. If you are using Kajabi's built-in email tool or a third-party platform like ConvertKit, the accessibility expectations are identical.

The quick audit: twenty minutes with your own course

Here is a twenty-minute self-audit you can run on any course you sell.

Open a private or incognito browser window. Go to your course sales page. Without using your mouse at all, press Tab repeatedly until you reach the buy button. Every interactive element should be reachable, and you should be able to see where you are on the page (a visible focus outline). Buy the course (use a test coupon or refund after).

Now log in to the course as a student. Tab through the lesson navigation. Open a lesson. Play a video. Turn on captions. Are they accurate? Tab to the next lesson. Download a PDF worksheet. Open it. Can you select the text?

If any of those steps break, you have found your first remediation item.

Platform-specific notes

Teachable. Alt-text fields exist on image uploads but are not required. Theme defaults are reasonably accessible; heavily customized themes often introduce contrast problems in button and link colors. Caption upload uses .vtt format.

Kajabi. The page builder is powerful and therefore easy to break. Watch for low-contrast text on gradient backgrounds. Kajabi's offer pages use a default hero-video block that autoplays with sound -- turn that off. Caption support uses .vtt files on Wistia-hosted videos.

Thinkific. Alt-text support is good across all upload flows. Caption upload is straightforward. Their Site Builder includes an accessibility checker that catches some common issues; run it before publishing.

Podia. Simpler platform with fewer customization options, which often means fewer accessibility breaks. Caption support is solid. Watch for long sales-page layouts rendered as a single image -- this is a common failure mode for creators migrating from Instagram-style pages.

LearnWorlds. More enterprise-oriented; accessibility is better than average for a hosted platform. Their built-in video player supports captions, audio descriptions, and transcripts. Use all three for any course that includes visual-only content.

Mighty Networks. Community-oriented; most accessibility problems show up in user-generated content (member posts, comments). As the host, you are still responsible for the platform meeting WCAG 2.2 AA.

What to do if you receive a demand letter

If a plaintiff sends you a pre-litigation demand letter alleging your course is inaccessible, do three things before responding.

First, do not panic and do not pay immediately. Many letters are boilerplate and overstate the damages the plaintiff could actually recover.

Second, get a real audit from a qualified accessibility professional. A letter from a plaintiff's attorney does not substitute for a neutral audit of your actual content.

Third, engage an attorney who has handled ADA or Unruh Act accessibility claims before. This is a specialized area; a general small-business attorney is likely to recommend settlement amounts that are higher than necessary.

If you want background reading while you work out next steps, our guide to responding to an accessibility complaint walks through the first seventy-two hours in detail.

The bigger picture

Accessibility on course platforms is not a one-time fix. Each new course adds new videos, new PDFs, new emails. The goal is to build the habits into your production workflow so that captions, alt text, and readable PDFs are done by default, not retrofitted after a complaint.

You do not need to be a developer to run an accessible course business. You need to know which twenty percent of the work your platform doesn't do for you, and you need to do that twenty percent every time you launch.

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

DEV Community: AgentKit

Product Image Zoom and Lightbox Galleries: The Accessibility Trap in Almost Every Online Store

Why the image gallery matters more than you think

The five failures that show up over and over

1. The photo is not a real button

2. Escape doesn't close it

3. Focus escapes behind the overlay

4. Focus is lost on close

5. Every image says the same thing (or nothing)

The ten-minute audit

What to actually ask for

The part worth remembering

Related Reading

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

Why this particular widget is such a reliable failure

The WCAG 2.2 criterion that applies

Test yours in five minutes

Your four options, from best to worst

Option 1: Replace the slider with two labelled images

Option 2: Keep the slider, add real controls

Option 3: Add a plain toggle button

Option 4: Fix only the alt text

Writing alt text for before-and-after photos

What to say to your web person

Why this is worth your afternoon

Related Reading

Sign in with Google, Apple, or Facebook: Why Social Login Buttons Fail Accessibility Tests

Failure 1: The button has no name a screen reader can read

Failure 2: The brand colors do not meet contrast requirements

Failure 3: The popup window nobody announces

Failure 4: Coming back from the provider, focus lands nowhere

Failure 5: The dead-end error message

Failure 6: The keyboard path through the login box is a mess

Failure 7: Only offering social login

How to test your own login in ten minutes

What to send your developer or vendor

The takeaway

Related Reading

Back to School, Nine Months to the Deadline: A School Website Accessibility Checklist

Why school websites fail, specifically

The seven things to fix, in order of who gets hurt

1. The PDF problem

2. Flyers posted as images

3. Closure and emergency announcements

4. Video without captions

5. Staff directories and contact forms

6. Third-party embeds you did not build

7. School colors and contrast

A realistic plan for the school year

One thing not to do

The honest summary

Related Reading

The Drag-to-Filter Price Slider Is Quietly Locking Out a Chunk of Your Shoppers

Why a price slider is harder than it looks

The three ways it breaks

1. Keyboard users can't move the handles at all

2. Screen reader users hear nothing useful

3. The handles are too small to grab -- for everyone

The 60-second test any store owner can run

What a genuinely accessible price filter looks like

Why this is worth your attention

Related Reading

Memorial Day Sale Banners and Pop-Ups: Five Accessibility Mistakes Small Businesses Make This Week

Mistake 1: The discount code is on a photo with no contrast

Mistake 2: The pop-up has no way to close it with a keyboard

Mistake 3: The countdown timer has no text alternative

Mistake 4: The "Shop Now" button is a div with a background image

Mistake 5: The exclusive email-only code is gated behind a CAPTCHA

A thirty-minute Memorial Day weekend audit checklist

What to do after the weekend

Related reading

Why Your 'Added to Cart' Toast Notification Never Reaches Screen Reader Users (And the Two-Line Fix)

What a toast notification actually is

The two-line fix: aria-live

The subtle part: where the region lives matters

What about Shopify, WooCommerce, Squarespace, and Wix?

How to test in five minutes without coding

Why this matters more than it looks like it matters

A quick mental model for the next time you ship a notification

Related Reading