Are Shopify announcement bars accessible to screen readers?
Announcement bars sit at the top of every page, so one inaccessible bar is a failure repeated everywhere. What breaks and the markup that fixes it.
Why announcement bars fail
Announcement bars look simple: a strip of text about free shipping or a sale. But they are often built as generic divs injected by apps, with no semantic role, no heading structure, and sometimes auto-rotating messages that change while a screen reader is mid-sentence. A sighted shopper glances at the bar and moves on. A screen reader user gets the announcement read aloud on every page load, or never hears it at all, depending on how badly it is built.
The repetition is what makes this expensive. A bar appears on the homepage, collection pages, product pages, and cart. An accessibility failure in one component becomes dozens of failures across the site, which is exactly the pattern that shows up in ADA demand letters.
The screen reader experience
Test it yourself with any screen reader: load the homepage and listen to the first thing announced. A good bar announces once, briefly, and then stays out of the way. A bad bar announces on every page navigation, interrupts the main content announcement, or traps the virtual cursor in a rotating carousel of promotions that never stops changing.
Rotating announcements are the worst offenders. Each rotation re-announces, so a shopper trying to read the product list hears sale messaging injected between items. If the rotation cannot be paused, it also fails the WCAG pause criterion for moving content.
The correct pattern
The accessible pattern is straightforward. Mark the bar as complementary content with an aria-label like "Site announcement", or use a simple paragraph inside the header landmark. If the bar rotates messages, add pause and previous/next controls that work by keyboard, and stop rotation on hover and focus. Never auto-rotate without a pause mechanism.
Keep the content short and static when possible. One message beats a carousel in almost every test: it is faster to announce, easier to understand, and simpler to maintain. If marketing insists on rotation, cap it at three messages and make the controls obvious.
How to test yours
Open your store with a screen reader and navigate to three different pages. Note what gets announced first each time and whether the bar interrupts anything. Then tab through the page: the bar should either be skippable or take exactly one tab stop. Check the rotation behavior by waiting thirty seconds on the homepage with the reader running.
Also test with the bar dismissed, if your theme offers a close button. The dismissal must work by keyboard, persist across pages, and be announced when activated. A close button that only works with a mouse strands keyboard users with a bar they cannot remove.
The fix list
Give the bar a landmark or label, make rotation pausable, ensure one tab stop maximum, and test dismissal by keyboard. These are small changes, usually under an hour of theme work, and they remove a failure that repeats on every page of the store. Announcement bars are also a common first finding in accessibility audits, so fixing yours proactively removes low-hanging fruit before anyone else finds it.
Dismissal persistence done right
Many bars offer a close button, which is good, but the dismissal has to persist. A bar that reappears on every page load despite being dismissed is worse than no close button at all: it teaches the user the control is fake. Store the dismissal in a cookie or local storage and respect it across the session at minimum.
When the bar is dismissed, announce the change politely and move focus sensibly, not to the top of the document. And when the announcement content changes, for example a new promotion, it is acceptable to show the bar again, but say so: screen reader users deserve to know why something they dismissed has returned.