DEV Community: AgentKit

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.

Loading Spinners Are Quietly Breaking Your Website for Screen Reader Users

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

Open a banking site and click "Pay Bill." For a second or two, the screen freezes, a small circular icon spins in the middle, and then the page jumps to a confirmation. A sighted user sees the spinner, sees it disappear, sees the new screen — and moves on without thinking. A screen reader user clicks the same button, hears nothing, then hears the confirmation screen begin reading from the top. The two-second gap between click and confirmation is a blank silence that costs trust and, increasingly, costs lawsuit money.

Loading states are everywhere on the modern web. They appear when forms submit, when search results load, when a cart updates, when a checkout finalises, when a chatbot is "thinking," when an AI search assistant is "writing." Designers spend hours making them feel snappy and on-brand — animated gradients, branded skeleton screens, witty progress messages. Almost none of those visual flourishes reach a screen reader. The user hears silence, and silence in software has a specific meaning: nothing is happening. So they click again. Or they hit Back. Or they assume the site is broken and call support.

This article is for non-developers — founders, content owners, marketing managers, designers — who need to understand why a spinner is an accessibility issue and how to make sure the fix actually lands on the engineering backlog. We will cover what the legal exposure looks like in 2026, what screen readers actually need to hear during a load, and exactly what to ask your team to change.

Why the silence is a real accessibility failure

The Web Content Accessibility Guidelines (WCAG) handle dynamic page changes through a specific success criterion called 4.1.3 Status Messages. The wording is dry, but the rule is simple: when the page changes state without moving keyboard focus — a loading state, a success message, a cart update, an inline error — that change must be announced to assistive technology programmatically. A visible spinner satisfies the visual side of the design. It does not satisfy 4.1.3 unless the spinner is accompanied by a live region that a screen reader picks up and reads aloud.

The 4.1.3 criterion is Level AA. That matters because every major accessibility law in 2026 — the European Accessibility Act, the US Department of Justice Title II rule that became enforceable in April 2026, the UK Public Sector Bodies Accessibility Regulations, the Section 508 update for US federal contractors, and the procurement standards in Canada, Australia, and Japan — references WCAG 2.1 AA as the compliance baseline. Failing 4.1.3 fails the law.

It is also one of the failures most likely to surface in a real user complaint rather than an automated scan. Spinners often pass an axe-core scan because there is nothing visibly wrong with the HTML — the failure is the absence of an aria-live announcement, not the presence of a bad element. The bug only shows up when a real screen reader user tries to use the site and hits a wall of silence.

What the silence sounds like in real life

Consider a small wedding-florist site that takes orders for arrangements. The order form has six fields. A customer using a screen reader fills them out, presses Place Order, and the site sends the request to the payment processor. While the processor verifies the card, the page shows a "Processing your order, please wait" spinner overlay for about four seconds.

A sighted customer sees the overlay, waits, and is rewarded with a confirmation screen. The screen reader customer presses Place Order, hears nothing for four seconds, assumes the click did not register, and presses Place Order again. The site double-charges the card. The customer calls customer service. The owner of the florist has a thirty-minute support call to refund the duplicate charge, and the customer never orders flowers from that site again.

Multiply that by every loading state on every site. A user who calls support to ask "did my order go through?" is the lucky outcome. The unlucky one is the user who silently goes to your competitor's site instead, and the worst outcome is the user who contacts a plaintiff's law firm because the silence cost them money or a missed appointment.

What an ADA demand letter looks like for a loading state failure

We have reviewed dozens of accessibility demand letters sent to small US businesses since the start of 2025. The letters are usually templated, run three to six pages, and cite specific WCAG criteria the demanding party claims to have tested. WCAG 4.1.3 Status Messages appears in roughly one in four letters now, up from almost zero in 2022. The specific complaint reads something like this:

"Your checkout page presents a loading indicator after the customer submits payment information. The indicator is visually presented but is not announced to assistive technology. JAWS, NVDA, and VoiceOver users receive no audio feedback during the loading period and cannot determine whether their submission has been accepted. This violates WCAG 2.1 Success Criterion 4.1.3 Status Messages."

The letter then typically demands either a settlement payment (commonly five to twenty thousand US dollars for small businesses, more for larger ones), a written commitment to remediate within a set timeline (usually 60 to 120 days), or both. The cost of fixing the underlying loading-state announcement is usually under an hour of developer time. The cost of not fixing it is far higher than that. Read our analysis of how much an ADA lawsuit actually costs for a sense of the range.

In the EU, the European Accessibility Act exposure is different in character but similar in size. A market-surveillance authority can issue a non-compliance order with a 30 to 90 day correction window, and continued failure can lead to fines that scale with company turnover. We have not yet seen a public EAA enforcement action specifically about a loading spinner, but the criterion is in scope and the act has been in force since June 2025. The first wave of enforcement is now landing in 2026.

What screen readers actually need to hear

A loading state needs to announce three things, in order:

First, that the load has started. When the user presses the button, the screen reader should hear something like "Submitting order, please wait." This confirms the click was received. The phrase should be brief — two to six words is plenty.

Second, optionally, that the load is still happening if it runs longer than expected. If the load takes more than ten seconds, an interim message like "Still processing, this can take up to thirty seconds" prevents the user from assuming the site has hung. Most loads finish in under three seconds and do not need an interim message.

Third, that the load has completed, with the outcome. "Order submitted successfully" or "There was a problem with your payment, please review the highlighted fields." The completion message is the most important of the three because it is what lets the user know they can act again.

The technical mechanism that delivers those announcements is an HTML attribute called aria-live. A region of the page marked with aria-live="polite" tells the screen reader to announce any text that appears inside it without interrupting the user. A region marked with aria-live="assertive" interrupts whatever the screen reader is currently saying to deliver the message immediately. For loading states, polite is usually the right choice; assertive is reserved for genuine emergencies like a session timeout warning.

The five places your site most likely has the bug

Based on the small-business sites we have audited in 2026, the loading-state announcement is missing most often in these places:

The checkout submit. The Place Order, Pay Now, or Submit Payment button on every e-commerce site. WooCommerce, Shopify, Wix Stores, Squarespace Commerce — all of them ship default loading spinners with no live region. We covered the WooCommerce-specific patterns in our WooCommerce accessibility checklist.

The contact-form submit. Contact Form 7, Gravity Forms, WPForms, Typeform, Tally — the form submission spinner is universally silent by default. The success message ("Thanks, we will be in touch") usually does appear in a live region in newer plugin versions, but the in-flight spinner does not.

The site-search results. As-you-type search results that update below the search bar are a classic 4.1.3 failure. Sighted users see the result count change ("12 results"); screen reader users hear nothing as they type and have no idea whether results exist.

The "Add to Cart" confirmation. AJAX add-to-cart buttons add the product to the cart and update the cart-icon counter without a page reload. The cart counter changes visually but the screen reader hears nothing, so users have no idea whether their click worked. Many users then add the same product a second or third time.

The chatbot "thinking" state. Live chat widgets, AI assistants, and customer-service bots all show a "typing" indicator while the response is generated. Almost none of them announce it. The user types a question, hears nothing, and waits, with no sense of whether the bot is working or stuck. Our chatbot and live chat accessibility guide covers the full pattern.

What to ask your developer (or your plugin vendor)

You do not need to know the code to spec the fix. Here is the conversation, in plain language:

"For every loading state on the site, please add a status message that screen readers can hear. The technical pattern is an aria-live region. When a load starts, the region should announce something like 'Submitting order, please wait.' When the load finishes, it should announce the outcome — success or failure. The announcement should not steal keyboard focus from wherever the user currently is. Please test the result with VoiceOver on macOS and NVDA on Windows, not just by looking at the visual page."

If you are using a no-code site builder (Wix, Squarespace, Webflow, Framer), the conversation is with the platform's support team or in a developer forum: "Does your checkout / contact form / search component support WCAG 4.1.3 Status Messages with an aria-live region? If not, when will it?" Most of the major platforms are catching up in 2026 because the EAA enforcement is putting pressure on them, but the default behaviour still fails in many cases.

If you are using a WordPress plugin (Contact Form 7, WPForms, Gravity Forms, WooCommerce extensions), check the plugin's accessibility statement or release notes for 4.1.3 support. WPForms Pro added proper status messages in version 1.8.5 (early 2026). Gravity Forms had support since 2.7. Contact Form 7 still requires manual customisation as of May 2026.

A simple browser test you can run today

You do not need a developer or a screen reader to start finding the bug. Here is a five-minute test that catches the worst offenders.

Open Chrome. Right-click anywhere on your site and choose Inspect. Click the Console tab at the top of the panel that opens. Paste this single line into the console and press Enter:

document.querySelectorAll('[role="status"], [aria-live]').forEach(el => console.log(el));

This prints every element on the page that is set up to announce status messages to screen readers. If you press the print button after clicking Add to Cart, Place Order, Submit Search, or any other action that triggers a spinner, you should see new elements logged or existing elements update. If you press the button and nothing appears in the console, your site has no programmatic announcement for that loading state.

This is not a full audit — it misses some patterns and gives false positives for others — but it is enough to start a conversation with your team. For a more comprehensive check, run a full five-minute accessibility audit on the same pages.

Why this matters more in 2026 than it did in 2024

Loading states have become more elaborate over the past two years. Generative-AI search, AI assistants embedded in checkout flows, real-time inventory updates, fraud-detection delays during card payment, and AI image generation during product personalisation have all added new loading patterns to ordinary e-commerce flows. Each new loading pattern is another chance to fail 4.1.3.

At the same time, screen reader software has become much better at handling well-implemented aria-live regions. NVDA 2024.3, JAWS 2025, and VoiceOver in macOS 14 and 15 all handle polite live regions reliably across Safari, Firefox, and Chromium-based browsers. There is no longer a good engineering reason to skip the announcement — the cross-browser, cross-screen-reader behaviour is solid.

And legally, both the US and the EU have moved into active enforcement. The Title II rule deadline came and went in April 2026 for state and local governments and any business that contracts with them. The EAA has been live for almost a year. Plaintiff law firms have templated the loading-state complaint and are sending it at volume. The window for treating spinners as a polish-pass nice-to-have is closed.

The fix is small. The risk of not fixing is not.

Adding an aria-live announcement to a single loading state is usually a one-line code change plus a one-line content change. A site with ten loading states typically takes a developer two to three hours to fix end-to-end, including testing with a real screen reader. Compare that to the cost of an ADA demand letter, a contracted accessibility consultant, or an EAA enforcement action: the math is not close. The reason the fix has not already shipped is almost always that no one with decision-making authority knew the bug existed. Now you do.

Walk through your site this week with a stopwatch. Every time you press a button that triggers a load — a checkout, a contact form, a search, a cart update, a chat — ask yourself: would a screen reader user know what just happened? If you cannot answer yes with confidence, that loading state is on the list.

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

Your Coffee Shop Mobile Ordering App Is the Next ADA Lawsuit Target — Here's Why

AgentKit — Tue, 12 May 2026 05:00:50 +0000

If you run a coffee shop, a café, or a third-wave specialty roaster, your mobile-ordering app is now your highest-revenue customer interaction. It is also, according to a federal appeals court that the Supreme Court declined to revisit, a place of public accommodation under the Americans with Disabilities Act. That makes it a legal liability the same way an inaccessible front door is — except your app is open 24 hours a day, used by hundreds of customers a week, and almost certainly has problems nobody on your team has noticed.

This article walks through, in plain English, why that liability exists, what plaintiffs' attorneys are actually filing against cafés right now, and the seven specific failures you can check yourself in an hour with nothing but the phone in your pocket.

The Robles v. Domino's decision is about your café, not just pizza

In 2019 a blind plaintiff named Guillermo Robles sued Domino's Pizza because he could not order a pizza through the Domino's website or mobile app using a screen reader. Domino's argued that the ADA applies only to physical buildings, not to apps. The Ninth Circuit Court of Appeals disagreed. They held that the ADA applies to the mobile app and the website because both are channels through which the Domino's stores — which are concededly places of public accommodation — connect with their customers. The Supreme Court declined to hear the appeal in October 2019, leaving the Ninth Circuit decision in place.

Robles is not a pizza decision. It is a quick-service-food decision. Every coffee shop with a mobile-ordering app is in the same legal posture as Domino's was in 2019, and the plaintiffs' bar knows it. Since 2024 we have seen a steady stream of demand letters against independent cafés and small chains in California, New York, Florida, and Pennsylvania, with the underlying complaint almost always the same: the blind plaintiff downloaded the app, tried to order, and could not complete a transaction independently.

Settlements typically run between $5,000 and $25,000 for an independent café, plus remediation costs, plus attorneys' fees, plus a multi-year monitoring obligation. For a chain of three or four locations, the range is $25,000 to $100,000. The defense costs alone — even on a case that ultimately settles — usually exceed $15,000.

The frustrating part for café owners is that almost none of these defects come from the café itself. They come from the off-the-shelf mobile-ordering platform — Toast, Square, Clover, Olo, Bbot, Square for Restaurants, Heartland Restaurant, or one of the dozen-odd specialty café-platform vendors. The café signed the platform contract, configured the menu, and turned it on. The platform vendor wrote the code that fails screen-reader testing. But the café, not the vendor, is the named defendant on the demand letter.

Test your own app in ten minutes — no developer required

You do not need any technical training to do a basic accessibility check on your café's mobile app. The phone in your pocket already has the tools built in. Here is the procedure.

If you have an iPhone: Open the Settings app, go to Accessibility, then VoiceOver. Turn VoiceOver on. Your screen now reads everything aloud as you touch it. Open your café's app and try to place an order using only spoken feedback — do not look at the screen. To turn VoiceOver off, press the side button three times (or whatever shortcut you set).

If you have an Android phone: Open Settings, go to Accessibility, then TalkBack. Turn TalkBack on. Open your café's app and try to place an order with TalkBack reading the screen aloud. The gesture pattern is different from iPhone — swipe right to advance, double-tap to activate — but the test is the same.

If you cannot complete the order — if buttons read out as "button" with no description, if size selections do not announce, if your loyalty balance is silent, if checkout traps you on a screen with no clear way forward — your customers with vision loss cannot complete the order either. They are not edge cases. The CDC estimates 7 million U.S. adults are blind or have serious vision impairment, and a much larger group has enough vision loss to rely on screen-reader settings on their phone.

Run through your most common order: large oat-milk latte, blueberry muffin, pickup in ten minutes. If you cannot do it with the screen reader on, neither can a real customer.

The seven failures we see on almost every café app

These are the specific defects that come up in nearly every audit we do of café and roaster mobile apps. Pull yours up while you read.

1. Menu-item buttons that read as "button" with no description

Tap a menu item with VoiceOver running. You should hear the item name, the price, and ideally the size or default customization. ("Oat milk vanilla latte, twelve ounces, five dollars seventy-five.") If you hear "button" or silence, the developer never attached an accessibility label to the menu-item card. Every customer with vision loss is now ordering by trial and error.

This is one of the easier defects to fix on the developer side, but only the developer can fix it. Take screenshots, file a support ticket with your platform vendor, and ask specifically for "menu-item accessibility labels conforming to WCAG 2.1 AA." Save the support-ticket reply — that documentation is the single best evidence you have in a demand-letter response if the vendor refuses or delays.

2. Size, milk, and syrup customization that uses horizontal-scroll carousels

The customization screen is the second-highest-failure surface. The standard pattern is a horizontal-scroll row of pills — "Small / Medium / Large" or "Whole / Oat / Almond / Soy / Coconut" — that screen readers either skip entirely or read in the wrong order. A blind customer can tap an option but cannot tell which one is selected, cannot tell what the price difference is, and cannot reliably proceed.

The fix is to replace carousels with native radio-button controls or a properly-labeled picker. Again, this is a platform-vendor change, not a café change. But you can document the problem and demand a fix.

3. Add-to-cart and checkout buttons that report no role to screen readers

Tap your add-to-cart button. VoiceOver should announce "Add to cart, button" or similar. If it says nothing, or says only "Add to cart" with no indication that it is interactive, the button was implemented as a generic view rather than as an actual button. The customer cannot reliably activate it.

Same fix path: screenshot, ticket, document the response.

4. Loyalty-rewards balance shown only as a graphic

Open the loyalty or rewards screen. With VoiceOver on, does it read your current point balance and the next reward threshold aloud? On most café apps it does not — the balance is rendered as a styled image with no accessible text equivalent, and the next-reward badge is a decorative graphic. A blind regular has no way to know how close they are to a free drink, what tier they are at, or how many more visits unlock the next perk.

The remediation is to render the balance as plain text that screen readers can read, with the visual styling layered on top. This is a one-day developer change, and it dramatically improves the everyday experience for the customer most likely to be a high-LTV regular.

5. Apple Pay and Google Pay flows that lose focus after the fingerprint scan

This one is subtle. When the customer taps "Pay with Apple Pay," the phone shows the fingerprint or Face ID screen, accepts the biometric, and then returns to the app. On a well-built app, focus moves to the order-confirmation screen and VoiceOver announces "Order confirmed." On a poorly-built app, focus disappears entirely — the screen reader goes silent, the customer does not know whether the order went through, and they end up tapping randomly until something speaks again.

You can reproduce this in two minutes with VoiceOver on. If you can, your customers with vision loss are panicking after every order.

6. Subscription enrollment that uses swipeable card stacks

If you sell a subscription coffee plan, the enrollment flow is almost certainly the worst page in the entire app from an accessibility standpoint. The frequency picker is often a card grid with no labels. The flavor-profile quiz is often a Tinder-style swipeable card stack that screen readers cannot operate at all.

The Federal Trade Commission's 2024 Negative Option Rule also requires that subscription-cancel be no harder than subscription-enroll. If your enrollment is inaccessible, your cancel-flow probably is too, which is a separate federal violation on top of the ADA exposure.

7. "Visit Us" page that hides hours, address, and accessibility info in images

This is not exactly a mobile-app failure — it is a website failure — but it costs cafés just as many customers. The "Visit Us" page is often the most-visited page on the entire café website, and it is also often the worst. Hours are rendered as a photograph of the printed door sign. The address is a styled card with no plain text. The wheelchair-access disclosure, the outdoor-seating availability, and the dog-friendly status are small icons with no alt text.

A wheelchair-using customer trying to confirm step-free entry before driving twenty minutes to your café has no reliable way to do so. Several recent demand letters specifically allege that an inaccessible "Visit Us" page constructively excluded the plaintiff from the physical store before they ever arrived.

This one you can fix yourself. Open your website's "Visit Us" page in your CMS. Replace every image of text with actual typed text. Add a plain-text accessibility section: "Step-free entry from the sidewalk. One accessible restroom on the ground floor. Two outdoor tables with no step. Service dogs welcome." Five minutes of typing, no developer required, removes one of the most common claim theories.

What to do this week if you are an independent café owner

You do not need to fix everything at once. Here is a realistic 30-day plan.

Week 1: Document. Run the VoiceOver test described above. Take screenshots of every place where the app or website fails to read aloud or fails to behave like a button. Save them in a folder. This is your evidence file.

Week 2: Vendor pressure. Open a support ticket with your mobile-ordering platform vendor — Toast, Square, Clover, Olo, whoever — and ask for their current VPAT, also known as an Accessibility Conformance Report. Every reputable vendor has one. If yours cannot produce one, that is your signal to start evaluating a switch. Document the request and the response.

Week 3: The fixes you control. Update your "Visit Us" page to plain text. Add a clearly visible phone number near the start of the page with a note: "If you have trouble ordering on the app or website, call us at [number] and we will take your order over the phone." Make sure someone is actually answering that phone during business hours.

Week 4: Statement and policy. Publish a brief accessibility statement on your website that names your ordering platform, acknowledges the work in progress, and tells customers how to contact you about accessibility concerns. This is not a magic shield against lawsuits, but it demonstrably reduces demand-letter volume because plaintiffs' firms screen for sites with no statement before sites with a statement.

The 30-day plan does not make your app perfect. It does dramatically reduce the size of the bullseye on your back, and it gives you a defensible position if a demand letter does arrive: documented vendor pressure, fixes within your control, and a clear customer-service path.

What this is really about

The reason every café owner should care about this is not the legal exposure. The legal exposure is real, but the reason to care is that the customer who cannot use your app is, almost by definition, the regular you most want to keep — a daily user, comfortable with your menu, brand-loyal, ordering the same drink at the same time every weekday. Mobile ordering exists to make that customer's life easier. If your app makes it harder, you are quietly losing the customer you most need.

The same is true for every accessibility issue. The cost of a fix is small. The cost of doing nothing is a customer who quietly stops coming.

Job Application Forms: The Accessibility Failures That Quietly Cost You Disabled Candidates

AgentKit — Mon, 11 May 2026 05:01:12 +0000

If you hire through a website -- a careers page, a Greenhouse job post, a LinkedIn Easy Apply listing, a Google Form, a PDF you ask people to email back -- there is a very good chance that disabled candidates are dropping out of your funnel before a human ever sees them. Not because they are not qualified. Because the application form does not work.

This is not a small problem. The U.S. Bureau of Labor Statistics puts the labor-force participation rate for people with disabilities at roughly 24%, compared with 67% for the rest of the population. A meaningful share of that gap is structural, and a meaningful share of the structural part is the application step itself: a date picker that cannot be reached with a keyboard, a CAPTCHA that demands you click pictures of buses, an "upload your resume" field with no label that screen readers can find, a multi-step wizard that loses your data when a screen reader pages back.

This article is for hiring managers, HR leads, founders, and small-business owners who are not developers but are responsible for a careers page that converts. We will cover what the law actually requires, the specific failures we see most often, how to test your own form in about ten minutes, and what to do when the form is on a platform you do not control.

The legal context, in plain English

In the United States, three layers of law apply to your job application form, even if your company is small.

ADA Title I (employment) covers any employer with 15 or more employees. The Equal Employment Opportunity Commission (EEOC) treats inaccessible application processes as a form of disability discrimination. The EEOC's published guidance is explicit: if your application "cannot be completed by an applicant with a disability without an accommodation," you are required to provide one, and you cannot use the inaccessibility as a basis for not hiring the person.

ADA Title III (public accommodations) covers any business that holds itself out as serving the public. Most federal courts now treat a public-facing careers page as falling within Title III, even if the company has fewer than 15 employees. Demand letters citing Title III violations on careers pages have been a steady part of the small-business legal landscape since 2021, and 2026 has seen a notable uptick.

Section 503 and OFCCP apply to federal contractors and subcontractors. If you do any work funded by the federal government -- including subcontracts -- your hiring process is subject to Section 503's affirmative-action obligations and the OFCCP's accessibility expectations, which lean on WCAG 2.1 AA.

In Europe, the European Accessibility Act, in force since 28 June 2025, treats consumer-facing digital services -- including the parts of your careers site that the public uses -- as in scope. Member-state regulators have begun enforcing against large employers and are working their way down to mid-market companies.

State laws layer on top: California's Unruh Civil Rights Act and FEHA, New York's State Human Rights Law, Colorado's HB21-1110, and others all create independent paths to liability that do not depend on the federal framework.

The combined practical takeaway: assume your careers page and application form have to be accessible. Assume the legal exposure is real even if you are small.

The seven failures we see in nearly every careers-page audit

These are the recurring patterns. If you have not specifically tested for them, your form almost certainly has at least three.

1. Resume upload field with no programmatic label

The "Upload your resume" control is often a styled <div> that triggers a hidden file input via JavaScript. Screen readers read it as "clickable" with no label. Keyboard users cannot tell what the control is for. The ATS company you bought this from probably has a fix in their changelog from 2023; it is just not enabled on your account.

How to fix: open the form on your own machine, press Tab until focus lands on the upload control, and listen with a screen reader (VoiceOver on Mac, Narrator on Windows). If the control is announced as "clickable" or "button" without saying what it does, file a support ticket with your applicant tracking system citing WCAG 1.3.1 (Info and Relationships) and 2.4.6 (Headings and Labels). Most ATS vendors will turn on a fix at the account level within a week.

2. CAPTCHA gating the submit button

A CAPTCHA -- "click all the pictures of crosswalks" -- on a job application is one of the highest-risk patterns in the entire industry. It locks out blind users almost completely (audio CAPTCHA is consistently below 50% intelligibility), it locks out users with cognitive disabilities, and it disproportionately filters out anyone using assistive technology that makes the page look unusual to bot detectors.

How to fix: turn the CAPTCHA off. If you have a bot problem, use a server-side bot detector (Cloudflare Turnstile, hCaptcha Enterprise's invisible mode) that does not require any user interaction. If your platform does not support invisible verification, switch to honeypot fields (an invisible field that bots fill in but humans cannot see). We have written about this in detail in Captcha Accessibility Alternatives.

3. Date pickers that cannot be reached with a keyboard

"Earliest available start date" is almost always a custom date picker. About half the ones we audit cannot be opened with the keyboard, navigated with arrow keys, or closed with Escape. A candidate who uses a switch device, voice control, or a head-tracker simply cannot complete the field.

How to fix: in the form designer for your ATS, change the date field type from "date picker" to "text input" with a placeholder format ("YYYY-MM-DD"). It is uglier. It works for everyone. If the ATS forces a picker, file a support ticket and, in the meantime, document that you accept resumes by email at an alternate address from any candidate who cannot complete the form.

4. Multi-page wizard that loses progress

Many ATSs split applications into 4 to 8 pages: contact, work history, education, voluntary disclosure, equal-employment questions. If a candidate using a screen reader pages back to fix an earlier answer, the form often resets the later pages. We have watched candidates reach the final page and lose 40 minutes of work.

How to fix: test it. Fill out your own application end to end, then page back from the last step and check whether the data on later steps survives. If it does not, escalate to the ATS vendor and, until they fix it, switch to a single-page application form.

5. Required field markers conveyed only by red color

Required fields are usually marked with a red asterisk (*) and red text. Color-blind users (about 8% of men and 0.5% of women) cannot distinguish red from black at small sizes. Screen readers do not announce color. As a result, a third of candidates with color-blindness fail validation on first submit, and a meaningful number of screen-reader users are unaware which fields are required at all.

How to fix: ensure every required field is marked with both the visible asterisk and the HTML required attribute (so screen readers announce "required"). The label text should also include the word "required" when the visual style is the only cue. Most ATSs have a "required-field accessibility" toggle in their admin -- find it and turn it on.

6. Voluntary disclosure forms that are not optional in practice

Federal contractors are required to invite applicants to self-identify as having a disability, as a veteran, and so on. The form is supposed to be voluntary. In practice, the disclosure step is often laid out so that "I do not wish to answer" is buried, the radio buttons are not in a fieldset, and the required-by-law disclaimer is unreadable to screen readers.

How to fix: rewrite the section so that "I do not wish to answer" is the first option, the disclaimer is a real <p> element with a meaningful aria-describedby link to the question, and the legal text is at least 14px with a 4.5:1 contrast ratio. The OFCCP-mandated language is published; you can paste it in directly.

7. Error messages that appear without focus or announcement

When a candidate submits with missing or invalid fields, the error messages typically appear as small red text near each field. There is no automatic focus shift, no scroll, and no role="alert" announcement. Sighted users on a phone may not notice a single short red line at the top of a long form. Screen-reader users hear nothing.

How to fix: ATS vendors generally have an account setting for this. Turn on "scroll to first error on submit" and "announce errors via aria-live region." If your platform does not support this, we have a longer walkthrough in Accessible Forms Guide covering the specific HTML and JavaScript patterns that make form errors usable for everyone.

How to audit your own application form in ten minutes

You do not need a developer to do this. You need a quiet ten minutes.

Open your job posting in a private browsing window so you are seeing it as a candidate would.
Apply with your keyboard only. Hit Tab from the top of the page. You should be able to reach every field, the resume upload, the submit button, and any modal or popover that opens. If the focus disappears or stops moving, you have a keyboard trap.
Turn on your operating-system screen reader (VoiceOver on Mac: Cmd+F5; Narrator on Windows: Ctrl+Win+Enter). Tab to each field and listen. Every field should announce its label and whether it is required. Buttons should announce what they do, not just "button."
Zoom your browser to 200% (Cmd+Plus or Ctrl+Plus). The form should still be usable. Text should not overlap; controls should not disappear; no horizontal scrolling should be required to read a single line.
Submit the form with deliberately wrong data (an invalid email, no phone number) and watch what happens. The page should tell you what went wrong, in text, near the bad field, and announce it to assistive technology.
Try to upload an unusual file type (a .pages file, a .odt file). The error should be helpful, not cryptic.
Time yourself. If a form takes longer than 15 minutes to complete with keyboard and screen reader, it is functionally inaccessible to many disabled candidates regardless of whether each individual control passes audit.

If two or more of those steps fail, you have material legal and pipeline exposure. Document it, escalate it to your ATS vendor, and -- in the meantime -- publish a clear alternate path: "Candidates who experience difficulty with our application form may email careers@yourcompany.com directly. We will respond within two business days."

Platform-specific quick notes

Greenhouse, Lever, Workable, BambooHR, JazzHR: all five publish accessibility statements and ship default forms that pass most automated audits. The most common failure on each is a specific custom field or workflow added by your hiring team. Audit your custom fields.

LinkedIn Easy Apply: generally accessible. The accessibility risk is in the screening questions you write. Avoid CAPTCHAs in screening questions; phrase yes/no questions with both choices visible; do not add a video-only response requirement without a written alternative.

Indeed Apply: known accessibility issues with the resume upload step on mobile screen readers. Until Indeed ships a fix, do not rely on Indeed Apply as your sole channel.

Google Forms: improved markedly in 2024-2025. Default forms are generally accessible. The risk is in long forms and in conditional logic, which can confuse screen readers.

PDF "fillable" application forms emailed back to the company: stop using these. PDFs are notoriously difficult to make accessible to screen readers, and asking a candidate to print, fill, scan, and email is itself an accessibility barrier. Move to a web form.

Custom-built careers pages: the highest risk. If your careers page was built by an agency more than two years ago, it almost certainly has issues. Run it through a free scanner (axe DevTools, WAVE) and through the manual ten-minute audit above.

What to put on your careers page

Three short things, in addition to the form itself:

A statement at the top of the careers page or the application form: "We are committed to providing equal opportunity to candidates with disabilities. If you need a reasonable accommodation to apply, contact careers@yourcompany.com or call (555) 123-4567 and we will respond within two business days."
An alternate-application path so candidates who cannot use the form have a documented alternative.
A link to your accessibility statement, or, if you do not have one yet, a short note that one is in development. We have a guide on writing one in Accessibility Statement Guide.

These three additions do not eliminate legal risk, but they significantly lower it, and they materially increase the percentage of disabled candidates who complete an application.

The bottom line

Job application forms sit at the most expensive point in the hiring funnel. You have spent money on the job ad, on the recruiter's time, on the listing fee. Losing qualified candidates at the form step because of accessibility bugs is both a legal risk and a direct hit to your hiring economics. The fixes are mostly small, mostly free, and mostly take less than a day to implement once you know what to look for.

The expensive part is not knowing.

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

Date Pickers Are the Most Common Accessibility Failure on Booking Sites — Here's Why

AgentKit — Mon, 11 May 2026 05:00:49 +0000

If you take bookings online, your customers are not failing to convert because of your photos or your pricing. They are failing to convert because they can't get past the date picker.

I have audited a lot of small-business booking flows in the last six months — salons, dental clinics, family photographers, dog groomers, tutors, restaurants, mobile mechanics — and the same defect shows up on every single one. Somewhere between "I want to book an appointment" and "thank you, your booking is confirmed," there is a calendar widget that is impossible or painful to use for an enormous share of the people trying to give you money.

This is not a niche problem. The U.S. Census Bureau estimates that around 13% of adults have some form of disability, and the World Bank puts the global figure at 15%. Many of those people use a screen reader, a keyboard instead of a mouse, voice control, a switch device, or a touchscreen with assistive features turned on. All of them try to book appointments. Almost none of them complete the date picker on a typical small-business website without help.

Here is what is going wrong on your site right now and what you can do about it this week — without writing a single line of code.

What screen reader users actually hear

Imagine your booking page is open. A screen reader user — let's call her Tasha — wants to schedule a haircut for next Saturday. She tabs through the page until she lands on your date picker.

On a well-built date picker, Tasha hears something like: "Choose a date, May 11 2026, edit text." She types "5/16/2026" and moves on. Done.

On the typical small-business booking widget, here is what she actually hears:

"Button. Button. Button. Button. Button. Button. Disabled. Disabled. Disabled. Button. Button..."

That's a calendar grid where every date has been built as a button with no label. The little visual numbers ("1", "2", "3"...) are images or background graphics that the screen reader can't read. Past dates are disabled buttons with no explanation. The current month and year are written somewhere on the page but not announced when the calendar opens. The "next month" arrow is an icon font with no accessible name.

Tasha has no idea what date she just selected. She has no idea what month she's looking at. She backs out, tries again, gets the same result, and books somewhere else.

You never see the abandoned booking in your analytics, because the booking never started.

The keyboard test you can run in 30 seconds

You do not need to install anything to find out whether your date picker is accessible. You need a keyboard.

Open your own booking page in any browser.
Click somewhere outside the form to make sure nothing is focused.
Press Tab repeatedly until a visible outline (a colored border, a glow, a box) lands on the date field.
Press Enter or Space to open the calendar.

Now answer three questions:

Can you see where you are? When the calendar opens, is there a clear, visible outline around one specific date — usually today's date or the date you'd previously selected? Or did the outline disappear entirely?
Can you move around with arrow keys? Press the left, right, up, and down arrow keys. Does the outline move from one date to the next, day by day or week by week? Or does nothing happen?
Can you pick a date and continue? Press Enter on the date you want. Does the date appear in the form field and the calendar close? Or does the focus get lost somewhere on the page?

If any of those failed, your date picker has a serious accessibility problem. You are losing customers right now, and you may have a legal compliance issue depending on where you operate. None of this is legal advice; talk to a qualified attorney about your specific situation.

The four ways date pickers fail

There are four patterns that account for almost every broken date picker I see on small-business sites. Knowing which one is on your site tells you what to do next.

1. The "fake calendar made of divs" pattern

This is the most common failure. The developer who built the booking widget used non-semantic HTML — a grid of <div> elements styled to look like a calendar, instead of using real buttons and a date input. The visual result looks identical, but to a screen reader the entire calendar is invisible and to a keyboard user it is impossible to operate.

You can identify this by tabbing into the calendar. If Tab moves to the first date and then jumps right past the rest of the calendar to the next field, you are looking at a fake calendar.

What to do: Ask your booking system vendor (Calendly, Acuity, Square Appointments, GlossGenius, Booksy, Vagaro, etc.) which date picker component they use and whether it conforms to the WAI-ARIA Authoring Practices for the date picker dialog pattern. If they don't know what that is, you have your answer.

2. The "no visible focus" pattern

The calendar works with a keyboard, but you can't see where you are. When you press the arrow keys, the focus is moving silently from date to date — but there is no visible outline, glow, or highlight that tells a sighted keyboard user which date is currently selected.

This fails WCAG 2.2 success criterion 2.4.7 (Focus Visible) and the new 2.2 criterion 2.4.11 (Focus Not Obscured). It also makes the calendar unusable for the very large group of users who can see but can't reliably use a mouse — people with tremors, repetitive strain injuries, certain motor disabilities, or who simply prefer keyboard navigation.

What to do: If your site is on Squarespace, Wix, Webflow, or another visual builder, check whether the date picker is part of the platform's native form block or a third-party embed. Native blocks usually have a fix (a setting somewhere called "show focus outline" or similar). Third-party embeds usually require you to either contact the vendor or replace the widget entirely.

3. The "month and year are invisible" pattern

You can navigate the calendar, but a screen reader user has no idea what month they're looking at. The month name ("May 2026") is written somewhere in the calendar header but not associated with the calendar in a way the screen reader announces. Or worse, the month is rendered as an image, an icon, or text styled in a way that the screen reader skips.

This is usually fixable without rebuilding the calendar — the platform just needs to use the correct ARIA attributes to label the calendar dialog. But if the vendor hasn't shipped that fix, you can't add it yourself on most no-code platforms.

What to do: This is one of the cases where a workaround beats a fix. Offer customers a plain text alternative right next to the calendar: "Or call/text us at (555) 123-4567 and we'll book you in." That's not a long-term accessibility solution, but it stops you from losing a real booking today.

4. The "mobile pinch zoom blocked" pattern

Your date picker works fine on a desktop, but on a phone it is built in a way that prevents the user from zooming in on the calendar grid to see the dates clearly. People with low vision rely on pinch-zoom to read interfaces, and any site that disables it fails WCAG 1.4.4 (Resize Text). Many booking widgets set user-scalable=no in their viewport meta tag, which silently disables zoom across the entire booking flow.

What to do: This one your developer or platform support team can fix in five minutes. Ask whoever maintains your site to remove user-scalable=no and maximum-scale=1 from the viewport meta tag if they exist.

What to do this week if you can't replace the widget

Replacing a booking system is a big project. You probably can't do it before Saturday. Here are four things you can do this week that meaningfully reduce the damage:

Add a visible phone number and "text us to book" button at the top of every booking page. Customers who can't use the date picker should not have to hunt for an alternative. Many of them won't.
Write a one-sentence accessibility statement linked from the footer that says you are aware of issues with the online booking flow and that you welcome phone, text, or email bookings. This is not a legal shield, but it shows good faith and gives customers a clear path forward. Talk to an attorney before publishing any compliance claim.
Train whoever answers your phone to recognize the call — "Hi, I'm trying to book online but the calendar isn't working for me." Make sure they don't try to send the caller back to the website. Just book the appointment.
Test your booking flow with VoiceOver on an iPhone. It is free, it takes 10 minutes, and it will tell you whether the rest of your booking flow (not just the date picker) is also broken. We wrote a separate guide on how to do this — see the related reading below.

The longer-term fix

The honest answer is that most small-business booking widgets are not great. The platforms know it. Some are better than others — Calendly's date picker has been significantly improved in recent releases, Square Appointments has made progress, and Cal.com is generally one of the most accessible options in the space. Many older booking platforms are still shipping date pickers that fail the keyboard test described above.

If you are choosing a new booking system in 2026, ask three questions before you sign up:

Does your date picker support keyboard navigation with arrow keys?
Does your date picker announce the month, year, and selected date to screen readers?
Have you published an accessibility statement, VPAT, or ACR for your booking widget?

If the vendor can't answer "yes" to question 1 and 2 with specifics, walk away. Question 3 is a nice-to-have that signals the vendor takes accessibility seriously, but the practical answers to 1 and 2 are what determine whether your customers can book.

A note on liability

ADA, EAA, and AODA-related lawsuits against small businesses over inaccessible online booking flows have grown sharply in the last two years. Plaintiffs' firms regularly file demand letters that name specific date pickers and booking widgets. Defending or settling a single demand letter typically costs many thousands of dollars and takes months. Fixing the underlying issue — or moving to a more accessible vendor — usually costs less than the defense.

This is not legal advice. Consult an attorney experienced in digital accessibility law in your jurisdiction before relying on any of the framing above for compliance decisions.

Countdown Timer Accessibility: Why Your Sale Widget Fails Screen Readers

AgentKit — Sun, 10 May 2026 05:00:34 +0000

Walk through a dozen Shopify or WooCommerce stores on a Saturday morning and you will see the same thing on most of them: a bright bar across the top of the screen counting down to the end of a sale. Two days, eleven hours, forty-two minutes, eighteen seconds. Seventeen. Sixteen.

For a sighted shopper this is just visual noise. You glance, you understand, you keep scrolling. For a screen reader user, a low-vision user with screen magnification, or a customer with a cognitive disability, that same widget is one of the most disruptive elements on the page. In some cases it makes the rest of the site unusable. In a few of the audits I have run this year, the countdown timer was the single biggest accessibility issue on an otherwise reasonable store -- and the owner had no idea, because they had never tested the page with the assistive technology that real customers use.

Memorial Day, Father's Day, the summer sale season, Prime Day, Black Friday. The next six months are the heaviest countdown-timer season of the year. If you are running an ecommerce site, this is worth thirty minutes of your time before the next promotion ships.

What screen reader users actually hear

Screen readers read the page out loud. The exact behaviour depends on which screen reader and which browser, but the way most countdown widgets are built today, the experience falls into one of three categories.

The "constant interruption" pattern. The timer is wrapped in an element with aria-live="polite" or aria-live="assertive", which is supposed to announce updates as they happen. The developer who installed it thought this was the accessible thing to do. In practice the browser fires an announcement every single second -- "two days eleven hours forty-two minutes seventeen seconds" -- and then again the next second, and the next. A screen reader user trying to read the product description gets every other word drowned out by a stopwatch reading itself out loud, forever, until they manage to navigate away from the page or turn off live regions globally.

The "invisible to assistive tech" pattern. The timer is implemented with CSS pseudo-elements (::before content), background images, or canvas drawing, none of which screen readers can access. A blind user has no idea the sale is ending in two days. They miss the urgency cue entirely, which is bad for them and bad for your conversion rate. If the urgency framing is what convinces a customer to buy, you are excluding a meaningful slice of your audience from the offer.

The "untrusted content" pattern. The timer is real DOM text but it is positioned fixed to the bottom of the screen, overlapping product photos and the add-to-cart button. On a phone in landscape it covers half the screen. Users with screen magnification cannot dismiss it. Users on small viewports cannot scroll past it. This is not strictly a screen reader issue, but it is the same family of problem -- a widget designed for one persona that breaks for everyone else.

All three patterns appear regularly in 2026 store audits. All three are easy to fix. Most store owners have never been told they exist.

The WCAG criteria a bad countdown timer breaks

If you have to justify the work to a client or a boss, here are the specific WCAG 2.2 success criteria a typical countdown timer fails. None of these are obscure -- all four are Level A or AA, which are the levels referenced by the European Accessibility Act, the Americans with Disabilities Act case law, and the Section 508 procurement standard.

2.2.2 Pause, Stop, Hide (Level A). Any moving, blinking, scrolling, or auto-updating content that lasts longer than five seconds must give the user a way to pause it, stop it, or hide it. A countdown that ticks every second for hours has no off switch on most ecommerce stores I audit. That fails 2.2.2 outright.

4.1.3 Status Messages (Level AA). Status messages that communicate change should be programmatically announced without taking focus from the user. The "constant interruption" pattern above takes the spirit of 4.1.3 and weaponises it -- the developer knew enough to add an aria-live region but did not understand that announcing every tick of the clock is exactly the failure mode the criterion is trying to prevent.

1.4.10 Reflow (Level AA). Content must reflow at 320 pixels wide without losing functionality. A countdown bar that uses absolute or fixed positioning often covers controls or pushes critical content off screen at small viewports. This is one of the most-cited issues in mobile accessibility audits.

1.4.13 Content on Hover or Focus (Level AA). Tooltip-style "ends in" overlays that appear on hover or focus must be dismissable without moving the pointer or focus. Many sale-popup timers fail this -- you hover over the icon, the timer fills the screen, and the only way to make it go away is to refresh the page.

You do not need to memorise these. You do need to understand that there is real, reasonably specific guidance for what to do, and that "we used a popular plugin" is not a defence in a demand letter.

How to test your own countdown widget in five minutes

You do not need a developer to do this. You do not need to install anything if you are on a Mac or a Windows machine with a screen reader already installed.

On a Mac: open Safari, navigate to your storefront, and press Command + F5 to turn on VoiceOver. Press Control + Option + A to start reading the page from the top. Listen for ten seconds. If you hear the timer announced over and over while VoiceOver is trying to read the rest of the page, you have the constant-interruption problem. If you hear nothing about a sale at all but you can see one on screen, you have the invisible-to-assistive-tech problem. Press Command + F5 again to turn VoiceOver off when you are done.

On a Windows machine: download the free NVDA screen reader, install it, and open Chrome. Press Insert + Down Arrow to start reading. Same listening exercise.

On any device: open your storefront, press Tab repeatedly with the keyboard only. If the countdown widget includes any interactive element (a "shop now" button, a close button, a "view details" link), it should appear in the tab order with a visible focus indicator. If it does not, it is failing keyboard users.

Five minutes total. You will know more about how disabled customers experience your store than the agency that built it.

What to ship instead

You do not have to remove urgency from your storefront. You do have to communicate it in a way that does not actively harm users on assistive technology. Three patterns that work in 2026:

Static end-of-sale text, not a ticking clock. "Sale ends Monday at midnight Eastern" is just as clear as a ticking countdown for almost every conversion-relevant decision. It does not announce itself every second, it does not require any clever ARIA, and it reflows perfectly. The only thing it loses is the visual drama of watching the clock tick. If your conversion lift from urgency depends on watching a clock tick, you have a different problem.

A countdown that updates in larger increments. If you must show live time, update only every minute (or every fifteen minutes if the sale lasts days), and use an aria-live="polite" region that contains only the new value, not the full timer. A screen reader user will hear "one hour fifteen minutes remaining" once a minute, which is informative without being maddening.

A countdown that is purely visual, with a screen-reader-only equivalent. Mark the visual ticking timer as aria-hidden="true" so assistive technology ignores it entirely, and put a visually-hidden static text element nearby that says "Sale ends Monday May 26 at 11:59 PM Eastern." Sighted users see the urgency, screen reader users get the same information without the noise.

Whichever pattern you choose, add a real close button with a visible focus state and a meaningful accessible name (not just an "X" character with no aria-label). Test at 320 pixel viewport width to confirm the bar does not overlap critical controls. If you are using a third-party app or plugin, check the developer's accessibility statement before installing -- and if there isn't one, that tells you something.

Platform-specific notes

Shopify. Most popular sale-app countdown timers (Hextom, Essential, Booster) install with the constant-interruption or invisible-to-assistive-tech pattern out of the box. The good news is that these apps usually support custom CSS and a "static text" mode hidden in their settings -- look for a toggle labelled something like "show end date instead of timer" or "compact mode". If the app you use does not have one, file a feature request and use a different app for the next promotion.

WooCommerce. Most countdown plugins (YITH, FuseWP, RWP) inject HTML directly into the theme. You can usually edit the template file in the plugin's settings to add aria-hidden="true" to the visual countdown wrapper and a visually-hidden static text alternative. If your developer is involved at all, this is a fifteen-minute fix.

Squarespace and Wix. The built-in countdown blocks are better than most third-party apps but still default to live ticking with aria-live. Hide the live region with custom CSS and add a static text block underneath for the same effect.

Custom builds. If your storefront was custom-built, ask the developer to confirm that the countdown widget passes 2.2.2, 4.1.3, 1.4.10, and 1.4.13. If they do not know what those mean, that is a useful signal about how much accessibility work is happening on your site in general.

What to do if you cannot change it before the next sale

You ship the promotion as-is, and you publish a short note in your accessibility statement acknowledging the issue. Something like: "Our current sale-period countdown widget may interrupt screen reader users. We are working with our platform vendor to replace it. In the meantime, please contact us at [email] for sale information in an alternative format." That note does not make you compliant, but it does demonstrate good faith, which matters in demand-letter triage and in serious-claim defence.

Then put a calendar reminder for the week after the sale to fix it for real. Most ecommerce store owners I have worked with discover that the fix takes one short conversation with their developer or app vendor, not a months-long project. The reason it has not been done is not that it is hard. It is that no one has ever pointed out the problem.

Now you have. The next promotion is the right time to ship the fix.

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

DEV Community: AgentKit

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

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

What a screen reader actually hears on a typical product page

Why this pattern keeps shipping

What an accessible swatch actually looks like

What you can do this week, by platform

The conversion case

The legal case

What to do in the next 30 minutes

Related Reading

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

The exact failure mode in plain English

Why this counts as a WCAG failure

Why the legal exposure is real, not theoretical

How to test for the bug in five minutes

How to fix it without rebuilding the page

What this means for your accessibility statement

A note on AI chatbot replacements for live chat

Related reading

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

Why bother if nobody is going to sue you next week

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

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

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

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

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

Day 6 (Wednesday, May 20): Tell someone

What to do on May 21

Related Reading

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

What is actually broken

The Web Content Accessibility Guidelines criterion this fails

How to check your own site in two minutes

What an actual demand letter looks like

What to ask your developer to do

Common objections, briefly answered

Why this is worth doing this week

Related Reading

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

Why this matters more than you probably think

What your platform actually handles

The five things that are actually your responsibility

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

2. Transcripts for audio-only content

3. PDFs that are actually readable

4. Sales pages that work without vision

5. Checkout and onboarding emails

The quick audit: twenty minutes with your own course

Platform-specific notes

What to do if you receive a demand letter

The bigger picture

Related Reading

Loading Spinners Are Quietly Breaking Your Website for Screen Reader Users

Why the silence is a real accessibility failure

What the silence sounds like in real life

What an ADA demand letter looks like for a loading state failure

What screen readers actually need to hear

The five places your site most likely has the bug

What to ask your developer (or your plugin vendor)

A simple browser test you can run today

Why this matters more in 2026 than it did in 2024

The fix is small. The risk of not fixing is not.