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

#a11y #webdev

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.