# Dave Davies - Checkout and Product-Page Accessibility

> Accessibility consultant helping £10M-£30M UK businesses increase ecommerce revenue and recover lost sales by removing accessibility barriers from product pages and checkout flows. Focused on conversion, not compliance box ticking.

This file contains the full text of every published article and video review on davedavies.dev, inlined as a single Markdown document for AI and LLM context. Each section begins with an H1 page title followed by a Source URL on the next line so models can cite back to the original page. Articles appear first in reverse chronological order, then video reviews in reverse chronological order.

# Six accessibility failures are blocking sales on almost every online store. Here is how to find yours.
Source: https://davedavies.dev/blog/webaim-2026-six-accessibility-failures/
Published: 2026-04-29

> WebAIM's 2026 Million report shows the same six issues are silently costing stores sales. Find them on yours, fix them, and stop losing customers your competitors are also losing.

## Summary

WebAIM's 2026 Million report identified six recurring issues that account for 96% of accessibility errors on the web. For online stores, each one is a drag on conversion. This article shows you how to find them on your own store in five minutes.

- 95.9% of the top one million home pages have issues that block at least some customers from completing a purchase.
- Online stores perform worse than the web average. Shopify stores averages 36.6% more issues per page than the typical site.
- 96% of these issues come from the same six problems, and the same six have topped the list every year for seven years.
- Stores that fix the basics enter the rare 4.1% that are open to every customer for business.

If you run an online store, [WebAIM's 2026 Million report](https://webaim.org/projects/million/) is worth your attention, because almost everything it identifies is a customer who tried to buy from a site like yours, but couldn't. Collectively, that is [costing UK businesses an estimated £17 billion every year](/blog/black-friday-cyber-monday-sales-advantage). Here's how to make sure you're not missing out on that.

That is the framing I would ask you to hold onto while you read the rest of this article. Accessibility, as a topic, is often easy to file under "_important but not urgent_". Lost sales aren't. Every lost sale is a customer who tried to buy from you and couldn't, and the report is a list of the most common reasons why.

Some of the numbers are striking. 95.9% of the top one million home pages have accessibility failures that block at least some customers from completing a purchase. And that number got worse this year, after six years of slow improvement - with online stores sitting among the worst performing categories in the entire report. [Shopify sites averaged 36.6% more issues than the typical page on the web](/blog/shopify-checkout-accessibility-product-pages/). Although it's worth noting that Shopify Checkout is highly accessible - it's the product pages which are letting you down.

The useful number, though, is 96%. That is the share of every issue WebAIM detected, across 56 million failures across a million sites, that comes from just six recurring problems. **The same six failures have topped the list every year for seven years.**

This is a short, stable, well-documented list of fixable issues. And the stores that work through this list and fix their failures end up in the rare 4.1% that are open to every customer for business, regardless of how those customers browse the web. The other 95.9% keep losing orders to the same six failures, year after year, while everyone wonders why their conversion rate is stuck.

## TL;DR for business leaders

- **Problem:** 96% of the issues stopping customers from buying come from six recurring failures, and online stores rank among the worst performers.
- **Impact:** Customers cannot complete purchases, your acquisition spend is wasted on traffic that bounces, and your store sits with the 95.9% rather than the rare 4.1%.
- **Fix:** Run a 5-minute diagnostic on the four pages that matter most, then work through the six issues in order of prevalence.
- **Result:** A measurable drop in unexplained drop-off, more completed orders, and a competitive position most of your category is failing to claim.

## Run this 5-minute test before you read on

Open Chrome, go to your busiest product page, and run [Google PageSpeed Insights](/start-here/product-page-accessibility-guide/) on the URL.

You are looking at the **Accessibility** score, not Performance. Scroll down to the audits section and you will see a list of issues. Most of what shows up there will map to one of the six problems below.

Now do the same on your home page, a category page, and your checkout. Five minutes, four pages, and you have a list of every automated issue on the journey your customers are actually walking.

**Two caveats before we go further.**

Automated tools find roughly 30% of issues that block customers. They are very good at finding the six failures in this article, because all six are mechanical and easy for software to detect. They are not good at the harder questions: does this make sense to a screen reader user, does this dropdown announce the right thing when a customer changes a size, can someone using only a keyboard actually get to your "add to bag" button without giving up first. For that, you need a human eye, which is the gap that [accessibility reviews](/reviews/) are designed to close.

A clean automated score also does not mean a perfectly accessible store. It means you have cleared the lowest bar. The reason that bar matters is that 96% of customers who get blocked are getting blocked at it.

**Onto the six.**

## 1. Low contrast text (found on 83.9% of stores)

Low contrast text is the most common problem on the web. WebAIM found an average of 34 separate instances of low contrast text on _every home page they tested_, up 15% in a single year.

Low contrast text often shows up as light grey body copy on white, white text laid over a pale lifestyle photo, or a brand colour button that looks crisp on the designer's monitor and washes out in sunlight. Sale tags are a regular offender, because the background flips between light and dark depending on the product image behind them.

**Who this blocks:** anyone with low vision, plenty of customers over 50, anyone with cataracts, anyone reading on a phone outside, anyone with a cheap monitor, anyone tired at the end of a working day. In practice, a meaningful chunk of your customers some of the time, including a lot of customers who would never describe themselves as having a disability.

**Sales cost:** people skim before they read. If your price, your "add to bag" button, your shipping copy, or your sale flag is hard to read, you lose them in the first second. They will not know they bounced because of contrast. They will just feel the page was hard work and go somewhere easier.

**How to spot it:** in PageSpeed Insights, look for the audit named "Background and foreground colours have a sufficient contrast ratio". Expand it to see every failing element on the page, with the contrast ratio it currently has and the ratio it needs. If you want to understand the science behind _why_ the ratio matters, here is a [full breakdown of WCAG colour contrast and the 4.5:1 ratio](/blog/wcag-colour-contrast-explained/). To stress-test how your contrast holds up under real use, [testing with browser zoom](/reviews/browser-zoom-testing/) shows what happens when a customer increases their browser zoom to read a page more comfortably, which a lot of older customers do as a default.

**What fixing it looks like:** mostly a design system fix. Pick contrast-safe defaults for body text, buttons, links, and labels, and stop overriding them with brand colours that fail. Most failures on a typical store come from three or four colour combinations being repeated across the site, so once you fix the system, the page-by-page work is small.

**What to brief your developer:** audit every text/background colour combination in the design system, adjust any that fail 4.5:1 (body text) or 3:1 (large text and UI components) until they pass, and update the design tokens so the fix propagates across the codebase.

## 2. Missing or weak alt text (53.1% of stores)

This one matters more for ecommerce than almost any other category, because product images carry a huge part of the buying decision.

The WebAIM report found that one in five linked images on the average home page has no alt text. On a product page, that means a screen reader user will often hear the filename, or just "image", instead of a description of what they are about to buy. Product images often show more than then written description covers (the fit, how it looks on the model, the way the fabric drapes, what the back of the product looks like) so the customer is left making a buying decision with half the information.

The [full guide to writing alt text for product images](/blog/how-to-write-alt-text-for-product-images/) covers what good descriptions look like across product photography, lifestyle imagery, and variants. The short version is below.

**Who this blocks:** screen reader users, obviously. But also anyone whose connection failed to load the image (more common than you might think), anyone using a text-based browser, and Google's image crawler, which is increasingly how products get surfaced in search and AI-generated answers. There is a separate piece on [how AI is becoming a sales channel that depends on accessibility](/blog/ai-as-a-sales-channel-accessibility/), and alt text is a large consideration.

**Sales cost:** if your product images do not carry their meaning into alt text, you become invisible to a slice of buyers. The slice is small in absolute terms, but it is also a slice your competitors are usually not serving either, which makes it disproportionately winnable.

**How to spot it:** in PageSpeed Insights, look for the audit named "Image elements have `[alt]` attributes". This catches images missing alt text entirely, but it will not catch weak or repetitive alt text (every image on a page being called "product image" or just the product name). For that, [this video on effective alt text for product pages](/reviews/effective-product-alt-text/) walks through what good and bad alt text actually look like in real use.

**What fixing it looks like:** there is a [full guide to writing alt text for product images](/blog/how-to-write-alt-text-for-product-images/) for the long version. The short version: describe what is relevant about the image to someone making a buying decision. The colour, the cut, the texture, the use case. Not "a t-shirt". A t-shirt in what?

If you are using AI to generate alt text, be careful. [A test of three AI alt text generators](/blog/can-ai-be-used-to-write-good-descriptive-alt-text/) showed mixed results. AI is a useful first draft, not a finished answer, and the gap between draft and finished is where the sales sit.

**What to brief your developer (and your content team):** make sure every image element has an `alt` attribute (even if empty for decorative images). On Shopify, WooCommerce, and most modern platforms, alt text lives on the image in the admin panel, so the content team can fix existing products without developer time. Bake it into the standard product upload process so the problem stops reappearing.

## 3. Missing form labels (51% of stores)

Half the web has at least one form field with no proper label. For a store, that almost always shows up in two places: the search bar in the header, and somewhere in checkout.

A form label is the bit of text that tells the customer what to type into a field. The common workarounds are to use placeholder text inside the field as a substitute, or to lean on an icon (a magnifying glass for search, for example) and assume that is enough. Neither works well. Placeholder text disappears the moment the field has focus, which is a problem for anyone who looks away mid-typing or has memory or attention difficulties. Icons get ignored by screen readers entirely.

This is the highest-stakes failure on the list, because it directly hits the part of your store where money changes hands. A confusing checkout form costs you sales from every customer, not only disabled ones. The accessibility fix and the conversion fix are, in this case, the same fix, which is why this would normally be the place to start for any store doing meaningful volume.

**How to spot it:** in PageSpeed Insights, look for the audit named "Form elements have associated labels".

**What fixing it looks like:** every form field gets an associated label. The label should be visible, not just announced to assistive technology, because everyone benefits from a label that does not disappear. The proper HTML pattern is `<label for="...">` paired with the field's `id`, or the field wrapped inside the label. Usually one line of HTML per field, and it is the kind of fix that can ship the same day someone notices it.

**What to brief your developer:** every form field needs a visible label, programmatically associated with its field. Placeholder text is fine as a hint (like a format example) but never as a substitute for a label. For search inputs and other icon-only inputs, either add a visible label or use an `aria-label` attribute that names the field.

## 4. Empty links (46.3% of stores)

An empty link is a link that contains no readable text. The most common offender on a store is the row of social icons in your footer, where each link contains an icon and nothing else. The cart icon in your header often has the same problem, as do search icons, hamburger menus, and "add to wishlist" hearts.

To a screen reader, every one of those announces as "link" with no further information. Voice control users cannot say "click cart link" because there is no readable text to match against, so the link might as well not exist. Multiply that across thousands of sessions a month and the number of customers who cannot reach your cart adds up to a real number of orders.

**How to spot it:** in PageSpeed Insights, look for the audit named "Links have a discernible name". To see the pattern in a real store, [this Pact Coffee review](/reviews/pact-coffee/) walks through how custom buttons end up empty even when they look perfectly normal to a sighted user, and [Where's your focus?](/reviews/wheres-your-focus/) shows what happens when these same links also break the keyboard journey.

**What fixing it looks like:** every icon link needs an accessible name. The cleanest fix is to add visible text alongside the icon, which often makes the design clearer for everyone. If the design genuinely demands icon-only, an `aria-label` attribute on the link does the job. Describe what it does, not what it is. "Open cart", not "shopping cart icon".

**What to brief your developer:** audit every link that contains only an icon or image, and add visible text alongside the icon wherever the design allows. Where the design demands icon-only, use `aria-label` (not `title`, which does nothing for screen readers in most cases). For dynamic states like a cart count, make sure the `aria-label` updates when the count changes.

## 5. Empty buttons (30.6% of stores)

The same problem as empty links, applied to buttons. Most often it is the close button on a modal (the X that dismisses a popup), the cart icon in the header, or a "quick view" button on a product card.

If a customer cannot dismiss your newsletter popup because the close button has no name, they are stuck on a page they did not want to be on, and the most common response is to close the tab. That is one of the more painful ways a store can lose a sale, because the customer did not even get to your product before you blocked them.

A lot of "buttons" on stores are not really buttons at all. They are custom controls that look like buttons but were built as styled `<div>` elements with click handlers. To assistive technology, those are invisible. [This custom dropdown review](/reviews/accessible-custom-dropdown/) and [this review of product options on a real store](/reviews/accessible-product-options/) both walk through this pattern, which is particularly common on Shopify stores using newer themes.

**How to spot it:** in PageSpeed Insights, look for the audit named "Buttons have an accessible name". For the deeper testing pattern, [this keyboard trap review](/reviews/keyboard-trap/) shows what happens when a customer cannot escape a control they did not mean to enter, which is usually how empty button problems play out in real journeys.

**What fixing it looks like:** every button needs an accessible name (visible text inside the button, or an `aria-label` if the design requires icon-only). And use a real `<button>` element, not a styled `<div>`. The browser gives you keyboard support, focus, and the right semantics for free if you use the right tag, which means a chunk of the work is already done before anyone writes any code.

**What to brief your developer:** every button needs an accessible name, and every "button" should actually be a `<button>` element rather than a styled `<div>`. For dynamic states (like a wishlist heart that toggles between empty and full), make sure the accessible name reflects the current state. Audit any modal popups specifically: the close button must have an accessible name and be reachable by keyboard.

## 6. Missing document language (13.5% of stores)

The quickest fix on the list, and the one most likely to be your developer's job rather than yours.

Every HTML page should declare its language with a `lang` attribute on the `<html>` tag. When this is missing, screen readers do not know which language to use, so they pronounce English content with whatever default voice the user has set. If their default is French, your product descriptions get read out in a French accent. It is bad enough that screen reader users often abandon a page entirely when it happens.

The sales cost is smaller than the other five, but the fix is so trivial there is no excuse for leaving it broken.

**How to spot it:** in PageSpeed Insights, look for the audits named "`<html>` element has a `[lang]` attribute" and "`<html>` element has a valid value for its `[lang]` attribute". The second one catches the case where someone has set the language but used an invalid code (like `lang="english"` instead of `lang="en"`).

**What fixing it looks like:** one line in your site's template. If you are on Shopify, WooCommerce, or any modern platform, this is usually already set correctly by the theme. If it is not, your developer can fix it in five minutes.

**What to brief your developer:** add `lang="en"` (or whatever language your store is in) to the `<html>` tag in the site template. For stores serving multiple languages, the attribute should change to match the active language version.

## Why the same six keep showing up

WebAIM has been running this report for seven years. The same six problems have topped it every single year. Page complexity has nearly doubled since 2019. ARIA usage is six times higher than it was. AI-assisted coding has made it faster than ever to ship new components, often without anyone reviewing whether they actually work for every customer.

The failures are not getting more sophisticated. They are getting more numerous, on more pages, in more places, because nobody is checking.

That is good news if you run a store. It means you do not need a full accessibility programme to leap ahead of your competitors. You need to fix six things, on every page that matters: home, category, product, cart, checkout. If you can do that, you are already in the top 4% of stores by usability for a slice of your customers your competitors are quietly losing.

## What to do this week

If you suspect customers are dropping out before they reach your checkout, here is the order to work in:

1. Run [PageSpeed Insights](https://pagespeed.web.dev/) on your home page, a category page, a product page, and your checkout. Note the accessibility score and the issues flagged.
2. Group the issues into the six buckets above. Most will fit cleanly.
3. Fix the highest-count issue first, which is usually contrast or alt text. Do not try to fix everything at once, and do not get distracted by issues that are not on the six.
4. Re-run the test. Watch the score move. Pick the next.
5. For the journey-based issues PageSpeed Insights cannot see (the dropdowns, the keyboard journeys, the screen reader experience on a real product page), work through the [free product page accessibility guide](/start-here/product-page-accessibility-guide/).
6. If you want a quick, specific steer on your own store rather than a generic checklist, [send me a URL](/contact/) or <a href='mailto:hello@davedavies.dev' data-plausible-event='Direct Email Click'>email me directly</a> and I will tell you where I would start.

The list is not getting any shorter, and your competitors are not fixing theirs.

# When the price isn't the price...
Source: https://davedavies.dev/blog/when-the-price-isnt-the-price/
Published: 2026-02-26

> If your product page shows two prices but doesn't clearly communicate which one applies, you introduce doubt at the worst possible moment. This article explores how unclear pricing affects conversion, and how to fix it properly.

## Summary

If a customer cannot confidently answer the question 'What will I be charged?' your product page has introduced risk into the buying journey.

- Screen readers often announce old and new prices without context.
- Visual clarity does not equal programmatic clarity.
- Doubt at the point of purchase reduces completion.
- Small markup changes can remove ambiguity without changing design.

Here's a quick quiz! What's the price of this item?

*Image: Product page showing two jacket images, a red “Sale” label, product title “Awesome product sale”, discounted price £135.99 reduced from £159.99, descriptive marketing text, and a prominent “Add to basket” button.*

You might say: Easy - It's £135.99. And you'd be right. But that’s because you can see it.

But unless this sale price is explicitly explained and exposed in the page markup, then for someone using a screen reader, both prices are just read out in sequence: "£135.99 £159.99".

**There's no indication of which is the real price.** It's exactly the same as showing two unstyled prices for everyone - which one is correct?

Now - a user _may_ infer that the lower price is the sale price. But they have to infer it, and that single moment causes doubt - and you don't want doubt.

You want clarity.

If you saw two prices and were not certain which one applied, would you confidently click Add to Basket?

If you saw two _unstyled_ prices and you weren't 100% sure which was the real price, would you still click Add to Basket? I'm not sure I would bother. You may be able to argue that if this was just the single point of failure on your product pages - you may be forgiven for some slight ambiguity. But are you sure that's the case?

And this is the whole point for testing your product pages. Remember - [not everyone shops like you do](https://davedavies.dev/blog/black-friday-cyber-monday-sales-advantage/).

## What does your code look like?

Here's what that code in that screenshot often looks like:

```html
<div>
  <span class="product-price__current">£135.99</span>
  <span class="product-price__previous">£159.99</span>
</div>
```

From a screen reader’s perspective, both prices are simply read in sequence. There is nothing in the markup that explains the relationship between them.

This is so common "in the wild" - and it's so easy to fix. Here's a tiny change that makes the pricing less broke, and more usable for everyone.

```html
<div>
  <span class="visually-hidden">Sale price:</span>
  <span class="product-price__current">£135.99</span>
  <span class="visually-hidden">Previous price:</span>
  <span class="product-price__previous">£159.99</span>
</div>
```

This is a small change in markup, but it removes the ambiguity completely. A more resilient implementation makes pricing relationships explicit.

A screen reader will now announce: "Sale price: £135.99, Previous price: £159.99". The relationship between the values is explicit. Ambiguity gone 🎉.

There are many ways you could fix this broken pattern, and the example above is just one way - but the point is it turns a confusing moment into a confident one. And it builds trust with your customer.

Here's another way. If you don't want any hidden text - then simply adding some text making it clear that this is the sale price. In this screenshot the price clearly tells you that the product is 20% off.

*Image: Product page showing a jacket on sale priced at £200 with “Save 20%” displayed next to it, previous price £250 struck through below, star rating with 875 reviews, size dropdown, and “Add to basket” button.*

**The principle is consistent: Meaning must be encoded in the markup, not inferred from styling.**

This makes sure every customer knows the price they'll pay - not just the ones who can visually see it.

## Why this matters beyond accessibility

As commerce expands across voice interfaces, AI shopping agents, and embedded experiences, [structured clarity becomes increasingly important](https://davedavies.dev/blog/ai-as-a-sales-channel-accessibility/).

Machines do not interpret colour, font size, or strikethrough as meaning. Instead, they rely on explicit labels, consistent structure, and deterministic state representation. Sounds familiar? It's almost as if building highly structured and easy to use product pages benefits everyone!

Accessible pricing is therefore not only more inclusive. It is machine-readable. And machine-readable systems scale. Ambiguity does not.

## Auditing your own pricing implementation

You can easily evaluate pricing clarity across your own product pages with a simple three-part review:

1. **Screen reader review - Use NVDA, VoiceOver, or JAWS.**

   Navigate to the price and listen carefully. Is the current price clearly identified? Is the previous price clearly described? Is there any ambiguity about which value applies?

2. **Markup inspection - Inspect the DOM.**

   Are prices distinguished structurally, or only stylistically? Does the order of elements reflect logical meaning? Are obsolete values still exposed?

3. **Interaction testing - Change a variant.**

   Is the new price announced? Is the old value removed or correctly hidden? Is the final payable amount explicit?

If any of these steps require interpretation, your pricing structure can be improved.

The core requirement is that your product page must clearly answer: What exactly will I be charged right now?

Not visually or stylistically. But structurally.

If the answer depends on inference, your page introduces unnecessary cognitive load.

If the answer is explicit in the markup, your page supports confident decision-making.

Clear pricing does not make a site impressive.

It makes it reliable.

And reliability is what protects conversion.

# AI is becoming a new sales channel. Here's how to make sure your products show up.
Source: https://davedavies.dev/blog/ai-as-a-sales-channel-accessibility/
Published: 2026-01-14

> AI is starting to influence how people discover and buy products online. This article explores what that shift means for your store, why accessibility matters beyond compliance, and how to keep your products visible as buying behaviour evolves.

## Summary

AI agents are emerging as a new sales channel. If your product pages introduce ambiguity, they cannot act with certainty, and the safest option for them is to skip your products entirely. How can you stop that happening to your products?

- AI shopping agents fail in the same places customers fail: unclear options, hidden prices, missing confirmation of actions.
- Accessible product pages make product identity, options, and outcomes explicit for both customers and AI agents.
- Removing ambiguity from product pages is the simplest way to stay visible as AI-driven shopping matures
- Focus on certainty. Clear product identity, predictable interactions, reliable outcomes

AI agents are starting to compare products and complete purchases on customers’ behalf. This is already happening inside search engines, marketplaces, and shopping apps. But agents can only recommend products from stores they can reliably understand, which means unclear and inaccessible product pages are increasingly invisible by default.

I'm not particularly an "AI will fix everything" person - but if you follow any AI news it's becoming increasingly clear that the largest technology platforms are pushing hard to turn AI into a place where shopping happens right in their apps, not just where people go to research or 'chat'.

And so if you're responsible for growth, revenue, or digital performance across your online store, then 

## Amazon has already been testing this - and it shows the risk

Amazon's recent **“Buy For Me”** experiment is a useful early signal - and the reaction from independent merchants shows what can go horribly wrong when agents act without enough certainty.

A recent to report in the [Financial Times](https://archive.is/20260107052832/https://www.ft.com/content/724c2910-76f2-45d7-8f2e-0ac5c82a5ad2) explained how independent retailers discovered their products being listed and sold through Amazon's AI-driven experience without consent, sometimes with incorrect information or stock availability. _Modern Retail_ also reported that merchants were unhappy with how Amazon positioned itself between them and their customers, including the use of Amazon-controlled relay email addresses that interfered with customer data and communication.

You can make moral arguments about this, but there's also a practical one: if an agent can't reliably use your site, someone else will try to "standardise" the experience for you.

While it's not entirely clear what went wrong with some of these stores, when a platform cannot reliably understand or transact on a merchant's site, it has an incentive to **proxy the experience**, standardise it, and pull it into its own system.

That standardisation often strips out nuance, brand control, and direct customer relationships.

The mere existence of opt-out mechanisms tells us something important: **merchants are going to care, increasingly, about how AI agents interact with their stores - and on what terms**.

## Where AI shopping agents commonly fail on product pages

Here's the reassuring part if you already care about customer experience.

**AI agents fail in many of the same places humans fail.**

On product pages, the most common problem areas seem to be **product variants** that change visually but not programmatically, **stock messages** that aren't clearly exposed, **price changes** that only appear after interaction, **add-to-cart actions** with no clear success or failure signal, and **errors communicated** only through colour, animation, or layout.

Without a 

## Being easy to understand is how your store stays visible as AI shopping grows

AI shopping isn't a distant prediction anymore. It's the clear direction of travel.

The stores that win won't be the loudest or the most experimental. They'll be the easiest to understand - for people and for machines.

If your store works well for customers who browse without a mouse, use a keyboard, or rely on assistive technologies, it's also far more likely to work well for AI agents deciding what to recommend and what to skip.

That's not a compliance argument.  
It's a commercial one.

Early adopters get the head start. Start by making your product pages unambiguous, then keep iterating as the channel matures.

# How to write good alt text for product images
Source: https://davedavies.dev/blog/how-to-write-alt-text-for-product-images/
Published: 2025-10-02

> Imagine scrolling through a website, but you can't see the images. How would you know what they contain? Learn how to write effective alt text that helps your customers, supports SEO, and makes your website more accessible.

## Summary

Alt text describes product images for people who cannot see them. On product pages, good alt text helps customers understand what is being sold, reduces uncertainty, and supports assistive technologies, search engines, and text-based browsing tools.

- Alt text should describe what the image shows and why it matters in the context of the page.
- On product pages, alt text should confirm key details of the product being shown - such as colour, style, variant and any defining features.
- The same image can require different alt text depending on the page purpose.
- Good alt text is clear, concise, and focused on customer understanding, not SEO keyword stuffing

Product images do a lot of work. They show colour, texture, fit, and details that help someone decide whether to buy. But if a customer can’t see those images, all of that information disappears unless you’ve described it properly.

Imagine scrolling through a website, but you can't see the images.

How would you know what they contain?

On product pages, missing or vague alt text often means a customer can't clearly understand what they're buying.

This is the daily reality for millions of people who use screen readers to navigate the web. Alt text (short for _alternative text_) describes what's in an image when they can't see it.

Done well, alt text is powerful. It makes sure no one misses out because of an image they couldn't see.

**The good news?** Writing good alt text isn't that complicated. It just takes a little thought and a clear focus on what your customer needs. And beyond accessibility, well-crafted alt text also supports SEO, helps when images fail to load, and provides context in text-only environments.

## What is alt text and why does it matter?

Alt text is the written description of an image that sits in your website's code. If the image doesn't load, or if someone is using a screen reader, the alt text is what gets read aloud instead.

Without it, all your customer hears is "image" - or worse, the filename - which is as unhelpful as it sounds. With it, they get the same information as everyone else.

*Image: Example graphic of code showing correct use of alt text*

That's a simple product photo described in a way that actually helps the customer decide if it's what they want.

## How to write good alt text

On product pages, alt text should help a customer confirm they're choosing the right item, not just describe what's visible.

Good alt text follows a few simple principles. Think of it as describing the image to someone who can't see it.

**What would be useful and helpful?**

**1) Be descriptive**  
Alt text should be as specific and accurate as possible. The goal is to give a clear idea of what the image shows and why it's there.

**2) Keep it concise**  
Good alt text is usually short - a few words to one sentence.

Focus on the essentials. If your image needs a lot of explanation (like a chart or infographic), provide a short summary in the alt and a fuller description in the page text.

**3) Skip "picture of..."**  
You don't need to start with "picture of" or "image of". Screen readers already announce that it's an image. Just describe what matters.

The only time you might name the type of image is if it adds meaning. For example, on an art site: "_Painting of sunflowers by Vincent van Gogh_" makes sense, because the format is important.

But on a product page, "_image of a blue cotton shirt_" is unnecessary - just write "_Blue cotton shirt with button-down collar_".

**4) Match the context**  
Alt text isn't just about describing what's visible. It should also reflect the purpose of the image on the page.

A photo of a bag of coffee beans could be described in many ways, but on a checkout page you'd want: "_250g bag of freshly roasted Arabica beans, ground for espresso_".

That description helps a customer confirm exactly what they're buying.

## Alt text examples: why context matters

The same image can need very different alt text depending on what the page is trying to do. What is the context of the image? Am I trying to show a blue shirt, a historical tour, or a modelling agency?

*Image: Example image of a person standing in front of historic stone arches*

The "correct" alt text depends on the purpose of the image on the page. In this photo by [Hans Town Kun](https://www.pexels.com/photo/contemplative-moment-in-historic-architecture-34045412/), are we:

- **Selling the shirt:**  
  `alt="Men's slim-fit navy button-up shirt with long sleeves and relaxed open collar"`  
  Focus shifts to the clothing - that's what the customer needs to know.

- **General description (on a personal bio page):**  
  `alt="Young man in a navy shirt leaning against a wooden railing in front of a stone wall"`  
  Focus on describing the person so visitors know who they're reading about.

- **On a travel blog:**  
  `alt="Person standing in front of historic stone arches"`  
  Here the building is the important detail, not the person's outfit.

*Image: Person and dog giving each other a high five on a sandy beach*

Here's a lifestyle photo where the story depends on context. In this photo by [Efrem Efre](https://www.pexels.com/photo/woman-and-australian-shepherd-high-five-on-beach-34035071/), we could feasibly use the following alt text:

- **Selling the jacket:**  
  `alt="Women's lightweight orange zip-up jacket with high collar and relaxed fit"`  
  Focus shifts to the clothing - that's what the customer needs to know.

- **General description (blog post about dogs):**  
  `alt="Person and dog giving each other a high five on a sandy beach"`  
  Focus is on the human connection and personality, giving visitors a sense of who they are.

- **On a travel blog:**  
  `alt="Person and dog on a sandy beach by the water with forest in the background"`  
  This focuses on the location and atmosphere, since the image supports a story about place.

## Final tips for writing alt text that works

Alt text isn't about ticking a compliance box or trying to please search engines. It's about making sure no customer is left out, no matter how they browse your site.

You'll do well if you just remember these 3 golden rules:

- **Be clear** - say what the image shows.
- **Be concise** - a short sentence is usually enough.
- **Match the context** - write what's most useful for the page it's on.

**Try this today:** pick three images on your site and rewrite the alt text using these rules. You'll see how quickly it becomes easier once you focus on purpose, not pixels.

Done well, alt text is invisible but powerful. It helps your customers, supports your SEO, and builds trust in your brand. Every image is a chance to welcome someone in, or shut them out.

Good alt text removes guesswork. It helps customers feel confident, and confidence is what leads to action.

# Shopify checkout is highly accessible - but your product pages might be costing you sales
Source: https://davedavies.dev/blog/shopify-checkout-accessibility-product-pages/
Published: 2025-09-12

> Discover why Shopify's checkout sets the standard for accessibility, and how six simple fixes to your product pages can stop you excluding up to 20% of potential customers and increase conversions.

## Summary

Shopify's checkout supports a wide range of customers, but most product pages will have accessibility barriers which can prevent people from completing a purchase. This article explains where those barriers appear, why they block customers from buying, and how to remove them.

- Shopify's checkout has great support for keyboard and screen reader users 'out-of-the-box'.
- Product pages are still the merchant's responsibility and are a common failure point.
- Customers who can't use your product pages never reach checkout, no matter how good it is.
- 94% of Ecommerce sites are reported to have inaccessible journeys. Fixing these is your competitive advantage.

If you lead ecommerce on Shopify, the platform gives you a strong checkout foundation. But that only helps if customers can reach it.

In practice, the biggest accessibility failures often happen on the product page template: the place where shoppers choose options, understand price changes, read delivery details, and decide whether to add to basket. If you want the broader commercial context first, [start here for free](/start-here/). If you want the Shopify-specific version, this article is for you.

Shopify has put real effort into making its checkout process accessible, which is good news for businesses. Customers who use a keyboard or screen reader can usually complete a purchase without barriers once they are inside checkout.

But that strength only matters if customers can reach it. If they struggle on your product page, your accessible checkout never gets the chance to convert them.

On peak shopping days like Black Friday and Cyber Monday, [accessible journeys give your business a measurable sales advantage](/blog/black-friday-cyber-monday-sales-advantage/) over inaccessible competitors. But the same principle applies every day of the year.

## TL;DR for business leaders

- **Problem:** If customers cannot use your product pages, they never reach Shopify's accessible checkout.
- **Impact:** You are excluding potential customers and wasting acquisition spend.
- **Fix:** Apply the six simple product-page improvements below.
- **Result:** More customers reach checkout with confidence and complete their purchase.

## Why Shopify checkout stands out

Shopify has publicly committed to following **WCAG 2.2 AA**, the internationally recognised accessibility standard. They also run regular usability testing with people who rely on assistive technology, such as screen readers.

So the final step of your sales funnel is already strong. The question is: **how do you make sure customers can actually reach it?**

## Six ways to make your product pages more accessible

Shopify gives you strong foundations, but your product pages are still your responsibility. Shopify even publishes its own [accessibility best practices](https://shopify.dev/docs/storefronts/themes/best-practices/accessibility). Here are six practical improvements you can apply to help more people buy from you.

### 1. Make product options easy to use

Customers need to be able to choose the right size, colour, or material whether they are using a mouse, a keyboard, or a screen reader. If those options do not work for everyone, some customers cannot buy at all.

_Example:_ On many sites, [option buttons are built using non-interactive code](/reviews/accessible-custom-dropdown/) such as a `<div>` styled to look clickable. These do not behave like real form controls, so they are invisible to screen readers and often unreachable by keyboard.

### 2. Add meaningful image descriptions

Photos sell your products. But if someone cannot see the image clearly, [they rely on short written descriptions](/reviews/effective-product-alt-text/). Instead of "Product image", say "Blue waterproof jacket with hood". Clear descriptions help customers make confident buying decisions.

_Example:_ Without alt text, some screen readers fall back to the file name, which is meaningless for a customer trying to confirm what they are buying.

### 3. Announce changes clearly

When a customer chooses a different option, the price or stock level might change. Make sure that update is obvious to everyone, including people using screen readers. If changes are not announced, customers may think nothing happened and abandon the flow.

_Example:_ On some sites, changing an option updates the price but no announcement is made. Customers only discover the change later, which creates uncertainty and drop-off.

### 4. Label every field and every button

From quantity boxes to "Add to basket", labels matter. They tell customers what each control does, and for assistive technology they are often the only way to understand and use those controls.

_Example:_ A quantity box without a label may be announced by a screen reader as "edit text" with no context. The customer has no idea what it controls.

### 5. Make sure focus is always visible

When customers navigate with a keyboard, they need to see where they are on the page. A clear focus highlight shows which button or link is currently active. Without it, navigation becomes guesswork.

_Example:_ On some sites, pressing `Tab` moves through the page but there is no visible outline showing where you are. Customers quickly lose track and abandon the journey.

### 6. Provide clear page structure

Customers should be able to scan your product page quickly and find product details, price, and delivery information. Use clear headings and consider adding a "Skip to product information" link to help people get there faster.

_Example:_ On many product pages, the actual product information is buried beneath complex navigation, banners, and media. For screen reader users, that often means a long, frustrating route to the content that actually matters.

## Quick self-check

Open one of your product pages right now and ask yourself:

- Can I choose a size or colour using only the keyboard?
- Do all product images have meaningful descriptions?
- If I change a product option, is the new price or stock level clear?
- Are all fields and buttons clearly labelled?
- Are buttons and swatches large enough to tap easily on mobile?
- Can I quickly scan the page and jump to the product details?

If the answer is "no" to any of these, customers are probably struggling before they ever reach Shopify's excellent checkout.

## Why this matters for your sales

When customers can use your product pages without barriers, more of them reach Shopify's accessible checkout - and more of them complete their order.

Accessible product pages do not just reduce drop-offs. They make your acquisition spend work harder, increase completion confidence, and reduce avoidable friction in the journey that matters most.

## The sales advantage of accessibility

Shopify's checkout already converts better than many alternatives - [around 15% better, in fact](https://www.shopify.com/in/enterprise/blog/shopify-checkout) - but you only benefit if customers reach it. Real businesses have shown the upside: stronger conversion, better retention, and clearer return on improvements that remove friction.

Accessibility is not just compliance. On Shopify, it is one of the clearest ways to make sure your strong checkout is not being undermined upstream.

## What to do next

If you use Shopify and suspect customers are dropping out before checkout:

1. Test your core product page template first, not just checkout.
2. Work through my [free product page accessibility guide](/start-here/product-page-accessibility-guide/) to spot the most common blockers.
3. If you want a quick steer on your own store, [send me a URL](/contact/) or <a href='mailto:hello@davedavies.dev' data-plausible-event='Direct Email Click'>email me directly</a> and I will tell you where I would start.

# Black Friday and Cyber Monday: why accessibility could be your biggest sales advantage
Source: https://davedavies.dev/blog/black-friday-cyber-monday-sales-advantage/
Published: 2025-08-27

> Learn how accessibility can directly increase your Black Friday and Cyber Monday sales. Discover how much revenue businesses lose to inaccessible websites, why loyal customers shop where they can, and how to prepare your product pages for the busiest weekend of the year.

## Summary

Black Friday and Cyber Monday can account for a significant share of your annual revenue. If customers cannot complete a purchase because of avoidable accessibility barriers, that revenue does not pause - it moves directly to a competitor.

- UK businesses lose £17.1 billion each year due to inaccessible websites, with nearly £446 million lost over BFCM weekend alone.
- Even small barriers on product pages and checkout can cost tens or hundreds of thousands in a single weekend for mid-sized businesses.
- Customers with access needs are highly loyal and often spend more with businesses they trust to work for them.
- Accessibility improvements before BFCM protect peak revenue, increase conversion, and strengthen long-term customer loyalty.

Black Friday and Cyber Monday (BFCM) are make-or-break moments for many businesses. In 2024, UK shoppers spent a whopping [£3.63 billion online across Black Friday and Cyber Monday](https://www.reuters.com/business/retail-consumer/britons-spent-46-bln-online-over-black-fridaycyber-monday-period-says-adobe-2024-12-03/). Globally, sales run into the trillions.

But here's a scary fact: if your website isn't accessible, a significant chunk of that spend will never reach you, and it'll go to your competitors instead.

Research shows UK businesses collectively lose [£17.1 billion a year](https://www.clickawaypound.com/) because shoppers using assistive technology abandon websites that don't work for them. During BFCM alone, that translates into nearly **£446 million in lost revenue**.

That's almost half a billion pounds walking out the door in one weekend.

## How much revenue can your business lose on Black Friday and Cyber Monday?

It's easy to dismiss numbers in the billions as "_someone else's problem_". But let's zoom in.

Black Friday & Cyber Monday can account for **[up to 15% of annual online sales](https://www.voguebusiness.com/consumers/black-friday-and-cyber-monday-did-they-work)**, with some businesses reporting that **[over 50% of their yearly sales happen across BFCM and the holiday period](https://woocommerce.com/posts/black-friday-stats-and-trends/)**. That means that if your business turns over £20 million a year, you could realistically be taking **£3-£4 million in sales over just one long weekend**.

Now imagine your product pages are inaccessible to just **2% of your customers**. That's a **£60,000 - £80,000 loss in a single weekend**. And that's a conservative calculation: research shows **10-15% of customers often click away** because of accessibility barriers.

At that level, you could be looking at **£300,000-£600,000** in lost revenue - all within 48 hours.

And the damage doesn't stop there. Accessibility problems don't just cost you one sale, they cost you repeat sales, loyalty, and lifetime value.

## Why customers with access needs stay loyal to accessible businesses

Disabled shoppers are among the most loyal customers online - provided you serve them well. The research is crystal clear:

- [83% of shoppers with access needs limit their purchases to websites they know are accessible](https://abilitynet.org.uk/news-blogs/research-shows-businesses-lose-17-billion-ignoring-accessibility-needs).
- 86% say they would spend more if sites were easier to use.
- 11% have paid more on an accessible site rather than buy cheaper elsewhere.

Accessibility doesn't just protect your BFCM sales, it earns you loyalty year-round.

And these customers are "_power shoppers_" too. [50% of consumers who use assistive technology shop online weekly](https://makeitfable.com/article/insights-the-state-of-online-shopping-for-people-with-disabilities/) (vs 22% of the general population). They often consolidate purchases with businesses they trust. Once you win them, they stay. Once you lose them, they rarely come back.

It's not just disabled customers either.

Older shoppers - who hold a disproportionate amount of disposable income - increasingly rely on larger text, clear navigation, and voice input. If your site isn't accessible, you're turning away your wealthiest demographic too.

## E-commerce sales are doubling - and accessibility will decide who wins

Global e-commerce isn't slowing down. According to [Morgan Stanley research](https://www.morganstanley.com/ideas/global-ecommerce-growth-forecast-2022), the e-commerce market is expected to nearly double by 2026. By that measure, **27% of all retail sales will be online purchases**.

The growth of e-commerce is proof that the way people shop has fundamentally changed. Without improved accessibility, customers with access needs risk being left behind. These are the very shoppers who stand to benefit most from the convenience of online retail - but unless websites work for them, they're excluded from what is rapidly becoming everyday life.

And for businesses, the upside is clear: a Forrester study found that every **$1 invested in accessibility** can yield **up to $100 in benefits**, from increased revenue to reduced support costs and stronger brand reputation ([TestParty via Forrester's findings](https://testparty.ai/blog/the-business-case-for-digital-accessibility)).

Accessibility isn't just a moral or compliance box to tick, it's a smart business choice with measurable returns.

## 5 simple ways to make the most of Black Friday and Cyber Monday with accessibility checks

The good news is that you don't need to be an accessibility expert to spot the biggest issues before November. A simple round of testing can reveal whether customers will be able to buy during your busiest sales weekend.

Here's a quick checklist you can try today. Run this quick test on your own product pages today. If you answer 'no' or even 'not sure' to one of these, your site is leaking sales.

1. **Do a no-mouse test.** Put your mouse aside and try to complete a purchase with just the keyboard (Tab, Shift+Tab, Enter, Space). If you can't, neither can your customers.
2. **Check your discount code box.** Can a screen reader pick up its label? If not, customers won't be able to claim your BFCM offers.
3. **Open and close your popups.** Do they trap you? Can you close them with Escape? Many shoppers will abandon your site if a promo banner blocks them.
4. **Resize text.** Zoom your browser to 200%. Does the layout still work? If it breaks, so will the sale.
5. **Run a free screen reader test.** VoiceOver (on iPhone/Mac) or NVDA (on Windows) are enough to catch serious issues. Try searching, adding to basket, and checking out.

These five steps won't uncover everything, but they'll give you a good start to show you whether customers with access needs can complete the journey.

## Accessible websites convert more sales on Black Friday and Cyber Monday

Every year, businesses pour money into advertising, discounts, and promotions for Black Friday and Cyber Monday. But if your website isn't accessible, a portion of that spend goes straight to your competitors - because customers arrive, try to buy, and then leave.

The question isn't whether customers with access needs will shop during Black Friday and Cyber Monday. They will. The question is: _will they shop with you, or with someone else?_

Accessibility isn't just about preventing lost revenue. It's one of the most effective ways to **increase your Black Friday and Cyber Monday sales**. If you want to make the most of the biggest shopping weekend of the year, make sure every customer can complete their purchase.

Start fixing accessibility today - it could be the difference between record sales or record losses this Black Friday and Cyber Monday.

# WCAG Colour Contrast: What does the 4.5:1 ratio actually mean?
Source: https://davedavies.dev/blog/wcag-colour-contrast-explained/
Published: 2025-01-31

> Ever wondered why WCAG sets a minimum contrast ratio of 4.5:1? It's not just a random number - it's based on how our eyes perceive brightness and what makes text readable. Let's break down the science of colour contrast, relative luminance, and why good contrast benefits everyone. From early accessibility research to how different colours contribute to brightness, we'll explore what these ratios really mean - and why they're essential for legibility in all conditions.

## Summary

WCAG's 4.5:1 colour contrast ratio is based on how the human eye perceives brightness, known as relative luminance. The ratio defines minimum contrast levels needed for readable text across different vision types and viewing conditions.

- The 4.5:1 ratio compares the brightness of foreground and background colours, not their hue.
- Relative luminance measures how much light a colour emits, which is what drives contrast.
- Different types of colour vision affect how contrast is perceived.
- The 4.5:1 ratio is the 3:1 display-standard baseline scaled up to compensate for reduced vision.
- Good colour contrast improves legibility for everyone, not just people with vision impairments.

Anyone who has worked with web accessibility will likely be familiar with the [WCAG Colour Contrast Requirements](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). These guidelines specify that text (and images of text) must have a contrast ratio of _at least_ 4.5:1 (at Level AA).

But have you ever wondered what that 4.5:1 ratio actually means?

This article explains where the contrast ratio comes from, how it's calculated, and why it improves readability in real-world conditions.

> Large text needs only a 3:1 ratio, because larger, wider strokes are easier to read at lower contrast. WCAG defines large text as at least 18pt (about 24px) at regular weight, or at least 14pt (about 18.66px) when bold. These are the Level AA thresholds; the stricter Level AAA raises them to 7:1 for body text and 4.5:1 for large text.

## Different types of colour vision

Not everyone sees colour the same way, and that matters a great deal when it comes to contrast. Colour blindness, or _Colour Vision Deficiency_ (CVD), affects roughly 1 in 12 men and 1 in 200 women. Usually it's a milder form, where one type of colour-sensing cone is weakened rather than missing entirely (a reduced sensitivity to green, called deuteranomaly, is the most common of all). The three main types, shown below at their strongest, are:

- **Protanopia** (red-weak): trouble telling red and green apart, with reds also looking darker
- **Deuteranopia** (green-weak): similar red-green confusion, but _without_ reds looking darker
- **Tritanopia** (blue-weak): trouble telling blue and yellow apart, and much rarer than the other two

Below is an interactive demonstration, using a photo from [Magda Ehlers on Pexels](https://www.pexels.com/photo/colour-text-1279813), that shows how people with different types of colour vision perceive the same colour spectrum.

You might notice that there's not much difference between _protanopia_ and _deuteranopia_ in the demonstration above. This isn't a mistake - both deficiencies are forms of red-green colour blindness that affect our eyes in _remarkably similar_ ways. The key difference? Protanopia affects the red-sensitive cone cells in our retinas, while deuteranopia affects the green-sensitive ones. Because these cone cells work together to help us distinguish colours, the end result looks quite similar, though protanopia tends to make reds appear slightly darker.

Tritanopia, on the other hand, looks noticeably different because it affects our blue-sensitive cone cells, which operate more _independently_ from the red and green receptors. This is why the tritanopia simulation shows such a distinct shift in how blues and yellows are perceived.

This visualisation helps explain why colour alone should never be used to convey information - what might be an obvious colour difference to someone with typical colour vision could be indistinguishable to someone with CVD. That's actually its own WCAG rule, [SC 1.4.1 Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) (Level A), and it's separate from contrast: it's about never relying on hue alone, like error text that's only red, or links set apart from body text by colour with no underline. This is why maintaining proper contrast ratios is crucial for accessibility, regardless of how users perceive colour.

## What the heck is relative luminance?

_Relative luminance_ is just a measure of how much light a colour gives off, on a scale from 0 (black) to 1 (white). It's worked out from the red, green and blue that make up a colour, but the three don't count equally: green makes up around 72% of the brightness we perceive, red about 21%, and blue only 7%. That's simply how sensitive our eyes are to each one.

This helps explain why some colour combinations are easier to read than others. It's also why _pure blue_ **(0,0,255)** looks so much darker than _pure green_ **(0,255,0)** to our eyes, even though both are cranked up to maximum: green pulls most of the weight, blue barely any. A _dramatic difference_ in luminance.

## So how is the ratio worked out?

If you like the specifics, the formula is `(L1 + 0.05) / (L2 + 0.05)` - the lighter colour's luminance over the darker one's, with a small `+0.05` added to each to allow for screen glare. That little offset is why the scale caps at 21:1 for black on white rather than shooting off to infinity, and it's also why 4.5:1 doesn't mean your text is literally four and a half times brighter.

You'll rarely do this by hand, mind you. But it's a genuinely useful thing to know that mid-grey `#767676` on white lands almost exactly on 4.5:1, which makes it about the darkest grey you can safely use for body text on a white background. Nudge it any lighter and it starts to fail.

> APCA (Accessible Perceptual Contrast Algorithm) is a newer, perceptually-based contrast method developed by Myndex Research. It was explored as a candidate for WCAG 3, but the W3C removed it from the WCAG 3 working draft in 2023, and as of 2026 the draft doesn't specify any contrast algorithm yet. WCAG 3 itself is still an early working draft (not expected to be finalised until the late 2020s), so WCAG 2.2's 4.5:1 remains the standard to build to today. APCA is worth knowing as a likely direction of travel, not a current requirement.

</Aside>

## Who decided that a 4.5:1 or 3:1 ratio was needed?

The numbers aren't plucked from thin air, and the reasoning behind them is actually quite neat. The **3:1 baseline** comes from older display standards: the minimum sensible contrast for someone with typical vision. The **4.5:1 figure builds on that**. People with moderately reduced vision (around 20/40) lose roughly a third of their contrast sensitivity, so the baseline was bumped up by half again to make up the difference. 3 times 1.5 is 4.5. The same reasoning gives the stricter AAA level its 7:1, aimed at weaker vision still.

And bear in mind that these colour contrast guidelines don't just affect those with poor eyesight. I'm certain we've all struggled to read text in bright sunlight or on badly designed websites. Studies consistently show that _everyone_ benefits from a minimum of a 4.5:1 colour contrast ratio when reading standard-sized text.

## Why these numbers matter in practice

Understanding the science behind contrast ratios, relative luminance, and colour vision deficiencies might seem academic, but it all comes together in practical application. When we combine our knowledge of how:

- Different cone cells interpret colours (as we saw in the colour blindness demonstration)
- Relative luminance affects perceived brightness (like why blue appears darker than green)
- Contrast ratios ensure readability (the 4.5:1 standard)

We can make better design decisions that work for everyone. For instance, that bright yellow text that passes contrast requirements on a white background? It might be _technically compliant_ at 4.5:1, but for someone with tritanopia, it could be nearly invisible. Or that subtle grey text that looks "sleek" on your monitor might become completely unreadable on a phone in sunlight.

This is why WCAG guidelines aren't just arbitrary numbers - they're carefully calculated standards that take into account the full spectrum of human vision, from typical colour vision to various types of CVD, from perfect lighting conditions to real-world scenarios. When we follow these guidelines, we're not just ticking boxes for accessibility compliance - we're creating interfaces that work better for everyone, in every situation.

## Tools for checking colour contrast

Getting colour contrast right takes a little care, but it pays off. Low-contrast text was found on a remarkable **83.9% of the top one million home pages** ([WebAIM Million, 2026](https://webaim.org/projects/million/)), making it the most common accessibility problem on the web. Happily, it's also one of the easiest to put right.

My go-to tool is the fantastically designed [colourcontrast.cc](https://colourcontrast.cc/). There are loads of tools which do this, but I love the design of this one and there's zero room for ambiguity. If you'd rather not leave the browser, Chrome and Edge DevTools show the contrast ratio right in the colour picker, with a pass/fail against AA and AAA and a "suggested colour" fix.

## The short version

When you're checking your own designs:

- Aim for **4.5:1** on body text and **3:1** on large text.
- Don't forget the other states: hover, focus, and placeholder text (placeholder still needs 4.5:1).
- Remember contrast isn't only about text: UI borders, icons and focus rings need 3:1 too ([SC 1.4.11](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html)).
- Never rely on colour alone to convey meaning ([SC 1.4.1](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html)).
- Run anything questionable through a contrast tool before you ship, and try a CVD simulator for colour-coded interfaces.

Get the contrast right and you're not just ticking a box for compliance: you're making your content readable for everyone, on every screen, in every lighting condition.

# How to build an accessible toggle switch with modern HTML & CSS (without JavaScript)
Source: https://davedavies.dev/blog/build-an-accessible-toggle-switch-with-modern-html-and-css-without-javascript/
Published: 2024-08-21

> Learn how to build an accessible toggle switch using modern HTML and CSS, without relying on JavaScript. This guide covers essential techniques to ensure your toggle switch is both functional and inclusive, and works in all browsers.

When your designer hands you a slick UI featuring toggle switches, your priority is to make sure these switches are accessible. So, how do you go about building an accessible toggle switch _without_ relying on JavaScript?

## Building an accessible toggle switch with HTML and CSS

JavaScript is a powerful tool, and I use it every day at work. However, browser vendors have _already_ equipped us with the necessary features to build accessible components without it. By using HTML and CSS, you can create a toggle switch that's both functional and accessible.

### Step 1: Start with an HTML Checkbox

At the very beginning, we'll start with a _well-structured HTML checkbox_. This uses an `<input>` element paired with a `<label>` element, ensuring they are correctly attributed and displaying a visible label.

```
<label for="toggle">
  <input type="checkbox" name="toggle" id="toggle" />
  This is the toggle label
</label>
```

*Image: An unstyled HTML radio form element*

To meet [WCAG 1.4.1 guidelines about not relying on colour alone](https://www.w3.org/WAI/WCAG21/Understanding/use-of-color), avoid conveying the checkbox status _solely_ through colour. Instead, we're going to add in two icons (sourced from Material UI) to indicate the state of the checkbox.

Place a `<span>` between the `checkbox` and the `label` to hold the check and cross icons. We'll then use a _pseudo-element_ to create a toggle that covers one icon at a time, visually indicating whether the checkbox is checked or unchecked.

```
<label class="toggle" for="toggle">
  <input type="checkbox" name="toggle" id="toggle" class="toggle__input" />

  <span class="toggle__display" hidden>
    <svg aria-hidden="true" focusable="false" class="toggle__icon toggle__icon--checkmark" width="18" height="14" viewBox="0 0 18 14" fill="none" xmlns="http://www.w3.org/2000/svg">
      <path d="M6.08471 10.6237L2.29164 6.83059L1 8.11313L6.08471 13.1978L17 2.28255L15.7175 1L6.08471 10.6237Z" fill="currentcolor" stroke="currentcolor" />
    </svg>
    <svg aria-hidden="true" focusable="false" class="toggle__icon toggle__icon--cross" width="13" height="13" viewBox="0 0 13 13" fill="none" xmlns="http://www.w3.org/2000/svg">
      <path d="M11.167 0L6.5 4.667L1.833 0L0 1.833L4.667 6.5L0 11.167L1.833 13L6.5 8.333L11.167 13L13 11.167L8.333 6.5L13 1.833L11.167 0Z" fill="currentcolor" />
    </svg>
  </span>

  This is the toggle label
</label>
```

**Key HTML considerations**

- **Using the `hidden` Attribute:** Apply the `hidden` attribute to the `<span>` containing the SVG icons. This ensures that if CSS fails to load, users still see a simple checkbox with a label. The hidden value will be overridden in CSS.
- **Aria Attributes:** Set `aria-hidden="true"` on the SVGs, as they are decorative and should not be announced by screen readers.
- **Focusability:** Add `focusable="false"` to the SVGs to prevent an issue in Internet Explorer where SVGs are focusable by default.

### Step 2: Style the toggle switch with CSS

Now that the HTML is in place, it's time to style our toggle switch to make it visually appealing and accessible.

```
/*
  Define colour variables using CSS custom properties for easy maintenance and theming.
  This allows for quick updates and supports light/dark mode switching.
*/
:root {
  --color-toggle-bg-default: #fbe4e2;
  --color-toggle-bg-checked: #cce6d0;
  --color-toggle-border: rgba(0, 0, 0, 0.2);
  --color-focus-ring: #4c9aff;
  --color-icon-checkmark: #006838;
  --color-icon-cross: #9e1b1b;
}

/*
  Set up the basic structure of the toggle component.
  Using flexbox to align items and create spacing between the elements.
*/
.toggle {
  display: flex;
  align-items: center;
  position: relative;
  cursor: pointer;
  gap: 1rem;
  flex-wrap: wrap;
}

/*
  Hide the actual checkbox input but keep it accessible.
  Position it absolutely to cover the toggle switch area, making the entire area clickable.
*/
.toggle__input {
  position: absolute;
  opacity: 0;
  width: 100%;
  height: 100%;
}

/*
  Styling the visual representation of the toggle switch.
  Using CSS variables for sizing and spacing, and applying a smooth transition for state changes.
*/
.toggle__display {
  --offset: 0.25em;
  --diameter: 1.8em;

  display: inline-flex;
  align-items: center;
  justify-content: space-around;
  box-sizing: content-box;
  width: calc(var(--diameter) * 2 + var(--offset) * 2);
  height: calc(var(--diameter) + var(--offset) * 2);
  border: 0.1em solid var(--color-toggle-border);
  position: relative;
  border-radius: 100vw;
  background-color: var(--color-toggle-bg-default);
  transition: background-color 250ms, transform 250ms;
}

/*
  The knob inside the toggle switch, which moves when toggled.
  Positioned absolutely inside the switch and centered vertically.
*/
.toggle__display::before {
  content: "";
  z-index: 2;
  position: absolute;
  top: 50%;
  inset-inline-start: var(--offset);
  box-sizing: border-box;
  width: var(--diameter);
  height: var(--diameter);
  border: 0.1em solid var(--color-toggle-border);
  border-radius: 50%;
  background-color: white;
  transform: translateX(0) translateY(-50%);
  will-change: transform;
  transition: transform 250ms;
}

/*
  Focus-visible is used to apply the focus ring only when navigating via keyboard.
  This prevents the focus ring from appearing during mouse clicks, enhancing the visual experience.
*/
.toggle__input:focus-visible + .toggle__display {
  outline: 2px solid var(--color-focus-ring);
  outline-offset: 4px;
}

/*
  Change the background color when the toggle is checked (active state).
  This applies the green color to indicate the "on" state.
*/
.toggle__input:checked + .toggle__display {
  background-color: var(--color-toggle-bg-checked);
}

/*
  Move the knob to the right when the toggle is checked.
  This visually represents the "on" state.
*/
.toggle__input:checked + .toggle__display::before {
  transform: translateX(100%) translateY(-50%);
}

/*
  Styling for the icons inside the toggle (e.g., checkmark and cross).
  Using inline-block for flexibility and inheriting colours for easy theming.
*/
.toggle__icon {
  display: inline-block;
  width: 1em;
  height: 1em;
  color: inherit;
  fill: currentcolor;
  vertical-align: middle;
  overflow: hidden;
}

/*
  Specific styling for the "cross" icon (used for "off" state).
  A slightly smaller size and dark red colour.
*/
.toggle__icon--cross {
  color: var(--color-icon-cross);
  font-size: 85%;
}

/*
  Specific styling for the "checkmark" icon (used for "on" state).
  A dark green colour that contrasts well with the light green background.
*/
.toggle__icon--checkmark {
  color: var(--color-icon-checkmark);
}
```

![Animation showing toggle switch in action](./images/toggle-switch-animation.gif)

## Ensuring accessibility in your toggle switch design

To create an accessible toggle switch, consider the following key areas:

### Focus state

A clear focus state is crucial. Ensure that your toggle switch's focus state is distinct and meets the required colour contrast ratios. Opt for `outline` over `box-shadow` for better accessibility.

### Clear labeling

Your toggle switch must have a clear label, either visible or provided via an `aria-label` attribute. This helps screen reader users understand the function of the switch.

## New Safari switch attribute

Safari recently introduced an exciting new feature: the input[switch] control, available in Safari 17.4+. This new control supports standardized pseudo-elements like `::thumb` and `::track` for styling form controls, moving away from the older `::-webkit` prefixed elements.

These advancements in Safari not only make CSS more maintainable but also allow for creative, interactive toggle designs. For example, Apple's Webkit blog features a Light/Dark mode toggle switch with embedded animations, showcasing the potential of these new features.

While these updates are promising, always consider the user experience. Toggle switches should be used in scenarios where a setting can be clearly understood as being either "on" or "off."

# How to create accessible charts in React: A guide to inclusive data visualisation
Source: https://davedavies.dev/blog/creating-effective-accessible-charts/
Published: 2024-08-08

> Data visualisation is key to communication but we found that many of the popular charting and graph libraries in ReactJS can be inaccessible to people using a screen reader. Ensuring accessibility in charts allows all users to understand and interact with your data. This guide explores how to create accessible charts using Highcharts, covering the selection of chart types, and the principles of clear chart design.

## What is accessibility in data visualisation

_Data visualisation_ is key to communication but we found that many of the popular charting and graph libraries in ReactJS can be inaccessible to people using a screen reader. Accessibility in data visualisation is essential to making sure that all users, regardless of how they consume that data, can understand and interact with charts and graphs on your website.

I've recently tested [Highcharts data visualization library](https://www.highcharts.com/) for a project at work, and have been impressed with its built-in tools and features for creating accessible charts in React. While [Highcharts requires a commercial license](https://shop.highcharts.com/), the quality and feature-set it provides outstrips any of the open source alternatives I've tested.

The biggest accessibility draw was the ability for users to navigate through the charts using a keyboard, with the data being read out in a useful and meaningful way. You can [explore Highcharts' interactive demo gallery](https://www.highcharts.com/demo) and [read their comprehensive documentation](https://www.highcharts.com/docs/index). However, we found their documentation for using Highcharts with React a bit limited, so we've spent some time experimenting and written 3 examples below for building a line chart, a spline chart and a bar chart in React.

## Choosing the right chart type

Different chart types _serve different data_ and _user needs_, making the selection process critical for effective and clear data visualisation. For example, **bar charts** are excellent for presenting categorical data and comparing values across multiple categories and subcategories. They clearly illustrate the differences between data points, making trends easy to spot. In this chart, each bar represents the sales figures for a different product category across four quarters, allowing for a straightforward comparison of sales performance within each category over time.

*Image: Bar chart titled 'Sales Performance by Product Category,' illustrating the sales figures (in thousands) for Electronics, Furniture, Clothing, Groceries, and Books across four quarters. The chart shows Groceries as the top-performing category in each quarter, with sales steadily increasing from Q1 to Q4, while Books have the lowest sales figures throughout the year.*

**Line charts** are ideal for visualising _data over time_, helping to illustrate trends, progressions, or changes in a continuous dataset. They are particularly useful when you need to show the relationship between different data points over time, such as tracking the performance of a product or monitoring the growth in website traffic over a period.

*Image: A line chart example, titled 'Monthly Sales Data' depicting example sales data (in thousands) across each month of the year.*

**Spline charts**, a variation of line charts, offer a smoother curve by using _splines_ (pronounced **/splaɪn/** - rhymes with line) instead of straight lines to connect data points. This type of chart is good for emphasising the smoothness of transitions or when the data represents a pattern that naturally follows a curved pattern, such as temperature changes throughout a day.

*Image: Spline chart titled 'Temperature Changes Throughout the Day' depicting temperature variations (in °C) from midnight to midnight. The chart shows a low of 12.5°C at 6 AM and a peak of 23.2°C at 3 PM, illustrating how the temperature rises during the morning and early afternoon and gradually cools down towards the evening.*

Choosing the right chart type is essential for clear and effective data visualization. Highcharts provides a wide range of chart types, including bar charts, line charts, spline charts, and scatter plots (plus many many more chart types), enabling you to select the best option tailored to your specific data and the insights you wish to convey.

## Creating accessible charts in React with Highcharts

Highcharts makes it easy to create _accessible charts_. Here's how to create a simple accessible line chart, spline chart & bar chart in a React application:

**Code example:**

In an existing React application, install the `highcharts` and `highcharts-react-official` packages:

```
npm install highcharts highcharts-react-official
```

### Create a line chart component:

```

// Initialise HighchartsAccessibility module
HighchartsAccessibility(Highcharts);

  const options = {
    title: {
      text: 'Monthly Sales Data'
    },
    xAxis: {
      categories: [
        'January', 'February', 'March', 'April', 'May', 'June',
        'July', 'August', 'September', 'October', 'November', 'December'
      ],
      title: {
        text: 'Month'
      }
    },
    yAxis: {
      title: {
        text: 'Sales (in thousands)'
      }
    },
    series: [
      {
        name: 'Sales',
        data: [29.9, 71.5, 106.4, 129.2, 144.0, 176.0, 135.6, 148.5, 216.4, 194.1, 95.6, 54.4]
      }
    ],
    accessibility: {
      enabled: true,
      description: 'This chart shows the monthly sales data over a year, with sales peaking in September and October.'
    }
  };

  return (
    
  );
};
```

In this line chart example, the `HighchartsAccessibility` module is imported and initialised to enable accessibility features. The accessibility option in the chart configuration provides a description for screen readers.

### Create a spline chart component:

You'll see in the example above that we're not actually telling Highcharts to return a line chart. Line charts seem to be the default chart type, so lets now get a Spline chart rendering instead.

```

// Initialise HighchartsAccessibility module
HighchartsAccessibility(Highcharts);

  const options = {
    chart: {
      type: 'spline'
    },
    title: {
      text: 'Temperature Changes Throughout the Day',
    },
    xAxis: {
      categories: [
        '12 AM', '1 AM', '2 AM', '3 AM', '4 AM', '5 AM', '6 AM', '7 AM', '8 AM', '9 AM',
        '10 AM', '11 AM', '12 PM', '1 PM', '2 PM', '3 PM', '4 PM', '5 PM', '6 PM', '7 PM',
        '8 PM', '9 PM', '10 PM', '11 PM'
      ],
      title: {
        text: 'Time of Day',
      },
    },
    yAxis: {
      title: {
        text: 'Temperature (°C)',
      },
    },
    series: [
      {
        name: 'Temperature',
        data: [
          14.0, 13.8, 13.5, 13.2, 13.0, 12.8, 12.5, 13.0, 14.5, 16.5,
          18.0, 19.5, 21.0, 22.5, 23.0, 23.2, 22.8, 21.5, 19.8, 18.2,
          17.0, 16.0, 15.2, 14.5
        ],
      },
    ],
    accessibility: {
      enabled: true,
      description:
        'This spline chart shows temperature variations throughout a day, with the lowest temperature observed early in the morning and the highest in the early afternoon.',
    },
  };

  return (
    
  );
};
```

The main difference here is that in the `options` object, we're defining a `chart` property with a type `key` set to `spline`.

### Create a bar chart component:

```

// Initialise HighchartsAccessibility module
HighchartsAccessibility(Highcharts);

  const options = {
    chart: {
      type: 'bar'
    },
    title: {
      text: 'Sales Performance by Product Category',
    },
    xAxis: {
      categories: ['Electronics', 'Furniture', 'Clothing', 'Groceries', 'Books'],
      title: {
        text: 'Product Categories',
      },
    },
    yAxis: {
      title: {
        text: 'Sales (in thousands)',
      },
    },
    series: [
      {
        name: 'Q1',
        data: [150, 200, 100, 250, 80],
      },
      {
        name: 'Q2',
        data: [170, 240, 120, 280, 90],
      },
      {
        name: 'Q3',
        data: [180, 260, 140, 300, 100],
      },
      {
        name: 'Q4',
        data: [200, 280, 160, 320, 120],
      },
    ],
    accessibility: {
      enabled: true,
      description:
        'This bar chart compares sales performance across different product categories over four quarters, with the highest sales consistently seen in Groceries and the lowest in Books.',
    },
  };

  return (
    
  );
};
```

In this bar chart example, once again all we need to update are the properties in the `options` object. This time we're defining a `type: 'bar'`, but you might also notice that we're returning 5 sets of data this time in the `series` property. Highcharts manages multiple datasets with ease, and still manages to organise that data in an intuitive way for screenreader users.

## Chart design best Practices

We always keep 3 points in mind when designing accessible charts:

- **Accessibility:** Design charts with _screen reader support_ and _high-contrast colours_ to accommodate all users.
- **Simplicity:** Keep charts _straightforward_ and _easy to interpret_, with clear and concise labels and annotations.
- **Colour considerations:** _Avoid relying solely on colour_ to convey information, ensuring the data is accessible to users with colour vision deficiencies.

Creating accessible charts is key to all users being able to read and interact with your visualisations. By following best practices developers can create clear, accessible & useful charts.

**Are your charts accessible to everyone?**

# Can AI be used to write good descriptive alt text for images in 2024?
Source: https://davedavies.dev/blog/can-ai-be-used-to-write-good-descriptive-alt-text/
Published: 2024-07-18

> Recent data from WebAIM shows that a third of the images on popular home pages have missing, questionable, or repetitive alternative text. This is a shocking statistic to have in 2024. Is AI good enough to write meaningful alt text for images? We tested three AI alt text generators to see how they perform.

## The importance of alt text for accessibility and SEO

Alt text on images is an _absolute basic_ of digital accessibility. Alt text (sometimes referred to as alt tags) is the _alternative text_ (or text description) of an image - providing some context of the image to users who cannot see it. This may include blind or low vision users, situations where the image doesn't load or is broken, and also includes search engine crawlers. **Alt text serves as descriptive text to convey the meaning and context of visual content in a digital setting**.

In the UK, [approximately 4.8% of UK adults have a vision disability](https://commonslibrary.parliament.uk/research-briefings/cbp-9602/) that often requires the use of assistive technology for accessing the web.

Understanding image content poses a critical challenge for individuals with visual impairments, which should always be your first consideration. Good quality alt text - and indeed providing a highly accessible website - boosts your SEO efforts and improves the experience for all users, while ensuring compliance with ADA and the [European Accessibility Act (EAA) coming into effect in 2025](https://www.deque.com/blog/european-accessibility-act-eaa-top-20-key-questions-answered/).

### Alt text provides context for humans

So providing alt text is a win-win for everyone, but writing good quality alt text is still hard. Many websites still have poorly written alt text or fail to use it entirely, leaving keyboard and assistive technology users frustrated or excluded. [WebAIM's study of one million homepages found that a third of images have missing, questionable, or repetitive alternative text](https://webaim.org/projects/million/#alttext).

This is a shocking statistic to have in 2024, so, with the rise of AI and Natural Language Models, can we now offload the role of writing alt text to a bot?

> Spoiler alert - No. While AI can provide some basic context and provide a good start to generating alt text, a human is still needed to "sense-check" the image and provide more context to the alt text that AI isn't able to.

## Qualities of good alt text

Good alt text should be _specific_, _concise_, and _relevant_ to the content and context of the image. It should avoid redundancy by not repeating information already provided by surrounding text. Additionally, it should capture the essential details without being overly descriptive.

**In short: to write good alt text, think about how you would describe that image to a friend.**

## Testing AI generated alt text generators

We tested three AI alt text generators for our evaluation: [AltText.ai's dedicated alt text service](https://altText.ai), [Ahrefs' free alt text generator tool](https://ahrefs.com/writing-tools/img-alt-text-generator), and [Protoolio's alt text generator](https://protoolio.com/alt-text-generator).

> Some of these AI alt text generator sites offered commission and affiliate links, but we aren't using any affiliate links for transparency.

### Criteria for choosing the tools

There are quite a lot of tools which claim to generate quality alt text using AI, but we wanted to narrow down our selection. The tools we chose matched the following criteria:

- It needs to be generally available to everyone. There exist some Shopify and Wordpress-specific tools which we didn't test.
- It needs a free tier, and we didn't want to create an account.

### Test Subjects

We chose 3 images to test the AI alt text generators. The images were selected to cover a range of scenarios and complexities to see how well the AI alt text generators could handle them. The images were:

- A [sunset photograph of a beach from Pixabay](./beach-sunset.jpg) (we thought the AI would find this one easy)
- A [photograph of Taylor Swift at the 2023 MTV Video Music Awards](./tay-tay.jpg) from Wikipedia
- An [infographic by Moz explaining the importance of alt text](./Alt-Text-Inforgraph.jpg)

### **The beach sunset photo from Pixabay**

*Image: Infographic titled \"How does alt text provide context for humans?\" explaining benefits: aids low/vision-impaired users, facilitates screen readers, and offers context for image load issues*

**AI generated results**

- **AltText.ai:** Infographic titled "How does alt text provide context for humans?" explaining benefits: aids low/vision-impaired users, facilitates screen readers, and offers context for image load issues.
- **Ahrefs:** Alt text: "Image showing various examples of alt text, demonstrating how it provides context for humans."
- **Protoolio:** Informative graphic by Moz explaining the importance of alt text in providing context for humans, particularly for individuals with low or impaired vision, users of screen readers, and addressing image load issues.

## Conclusion

We were actually surprised with how well some of the results came out. Clearly, AI has come a long way, and Generative Language Models are able to create fairly accurate and useful alt text. However, the nuances and specific contexts still require human oversight to ensure the alt text is truly beneficial for all users, especially those relying on assistive technologies.

# Why an accessibility bug costs more on a subscription page
Source: https://davedavies.dev/reviews/subscription-page-accessibility/
Published: 2026-05-20

The UK spends around £2.2 billion a year on fresh flowers and plants, and roughly a fifth of that goes online. It is a market that runs on a handful of intense weeks each year, and increasingly on subscriptions, where a single order becomes a relationship worth many times the first sale. This review looks at what happens when a flower subscription signup shuts out customers using a keyboard or a screen reader, and why that is one of the most expensive mistakes a store can make.

## What the review found

On the surface, the flower site in this review looks completely fine. But when you put the mouse away and move through a subscription product page with a keyboard, it falls apart before you reach the _Add to Cart_ button.

It's not unreasonable to assume that a customer might land straight on a product page - arriving from a link, an ad, a search result, or even [an AI answer](/blog/ai-as-a-sales-channel-accessibility/). So that is where this starts.

**And very quickly we find 3 expensive problems for this store owner.**

1. **The account and basket links never get focus.** `Tab` from the logo and you drop straight into the body of the page, past both, with no way back to either without a mouse.

2. Then the part that should stop any store owner in their tracks. **The choice between paying monthly and paying upfront cannot be reached at all.** The single control that decides whether this becomes a subscription or a one-off order, the most valuable decision on the page, is the one a keyboard cannot touch.

3. If you make it down as far as the form - we're invited to add a gift message, a recipient name, address, and postcode. However - **none of these form fields have accessible labels**, so a screen reader has nothing to announce. The entire form reads back as: "_Empty textbox. Empty textbox. Empty textbox._" This is the same experience as handing a sighted customer a form with every label invisible, and telling them to guess. Most will not.

And someone, somewhere, doesn't get their flowers 💔

## The same bug, a very different bill

Missing accessible names on form labels is one of the most common failures on the web, and one of the easiest fixes too. It may seem like a non-issue, but on a subscription page it is anything but.

If this page were selling a single £25 bouquet, the maths is simple. One customer cannot finish the form, so you lose one sale. £25, once.

But it is not a one-off. It is a subscription.

So you do not lose £25. You lose it this month, and again next month, and every month after, for as long as that customer would have stayed. A customer worth £25 a month for a year is a £300 customer. The label did not cost you a bouquet. It cost you the relationship.

Same bug. Same line of code. **A very different bill.**

Hold onto that, because it changes how you should weigh every fix. **The price of an accessibility bug is not set by the bug. It is set by the page.** The more a page is worth, the more the same failure costs you for every day it sits there. And the page where a customer signs up to pay you again and again is, by definition, one of the most valuable pages you own.

And it is not only flowers. [Coffee](/reviews/browser-zoom-testing/) and recipe boxes, refills, pet food on repeat, gym memberships, software trials: anywhere a customer can subscribe instead of buying once, the signup is the most expensive page on the site to get wrong.

## How to check your own subscription page

You do not need specialist tools for most of this. You need to put your mouse to one side.

1. Start on the subscription product page itself.
2. Press `Tab` through the page. Can you reach everything that matters: account, basket, the plan options, every field, the confirm button?
3. Reach the plan choice with the keyboard. Monthly or upfront, weekly or fortnightly.
4. Fill in the form without looking at the layout. Does each field tell you what it wants on its own?
5. Make a mistake on purpose. Leave a required field blank and try to continue. Is the error obvious, or does nothing seem to happen?

Then run a screen reader (NVDA, VoiceOver, or JAWS) through the same journey and listen. The form that reads back as _"empty textbox, empty textbox"_ is the one losing you customers you never see leave.

## What good looks like

None of the fixes are clever. They are mostly making the page behave the way customers already expect.

Every field gets a visible label, linked to the field, announced clearly, and still there when someone starts typing. The plan and billing options are built from real form controls, not styled elements that only answer to a mouse, so keyboard and screen reader support come built in. Account, basket, and every control sit in a sensible tab order with nothing skipped. And focus goes where the customer expects: into the form, onto the error when one appears, onto the confirmation when the order lands.

This is not a redesign. It is the difference between a page that takes every customer's money and a page that turns away the ones worth the most.

## The takeaway

The form label was the cheapest thing on that page to put right. Leaving it was the most expensive, because of what sat behind it: not one bouquet, but every bouquet that customer would ever have bought.

A bug on a product page costs you a sale.

A bug on a subscription page costs you a customer.

Test the page where the money repeats first. It is the one you can least afford to leave broken.

# The importance of effective alt text for product images
Source: https://davedavies.dev/reviews/effective-product-alt-text/
Published: 2026-03-18

Product images do more than show what something looks like. On a product page, customers are trying to understand exactly what they will receive. Images usually carry that detail. They show fit, colour, material, and how a product looks in use. But not every customer experiences those images in the same way. In those cases, what replaces the image needs to carry the same information. If it does not, key details are lost, and the product becomes harder to understand and compare.

## The job of an image changes depending on context

If you were asked to describe this image to someone in the next room, what would you say?

*Image: An unstyled HTML radio form element*

Context is important here, and the answer depends on where that image sits.

On a travel blog, the goal is to describe the scene: _**"Woman leaning against a wall in an industrial alleyway, looking off into the distance."**_

**The focus is the place. The mood. What is happening.**

But on a product page, the job is different. Now the image exists to help someone decide whether to buy. So the description needs to focus on what drives that decision:

- _Fit_
- _Colour_
- _Material_
- _Key features_

For the same image, that becomes something closer to: _**"Women's relaxed-fit burnt orange button-up shirt with long sleeves, styled with high-waisted green trousers."**_

**Same image. Different job.**

This is where useful alt text starts.

Not by describing everything in the image, but by describing the right thing for that context.

## Why this matters on product pages

For some customers, the image is not the primary way they understand a product.

The alt text is.

If that text is vague, generic, or repeated, key product details disappear:

- _What exactly is this item?_
- _How does it differ from other images?_
- _What would I actually receive?_

At that point, the product becomes harder to evaluate. And when something is harder to evaluate, confidence drops.

## A real example

In this review, I looked at a product page where every image technically had alt text.

So on the surface, everything looked fine.

It passed automated checks. But every image was described in the same, unuseful way.

No variation. No detail. And no product information.

Which means at the exact moment someone is trying to decide whether to buy, the page removes useful information instead of adding it.

There is no fit. No colour. No material. No meaningful difference between images.

That is not just an accessibility issue. It is a clarity issue in the buying journey.

## How to check your own product pages

Start with a simple test: _Ignore the image._

Read the alt text on its own and ask: _Would this help someone understand the product well enough to feel confident buying?_

**If not, the image description is not doing its job.**

If you've found gaps, read this [guide to writing effective alt text for product images](/blog/how-to-write-alt-text-for-product-images/).

## What good looks like

Good alt text does not try to describe everything. **It focuses on what helps someone decide.**

That usually means:

- _Naming the product clearly_
- _Including key attributes like fit, colour, and material_
- _Avoiding repetition across multiple images_
- _Adding detail where it changes understanding_

The goal is not completeness. The goal is clarity.

## The takeaway

Alt text is often treated as a technical requirement or an afterthough.

But on product pages, it plays a much bigger role. It is part of how customers understand what they are buying.

And when that understanding is unclear, the buying decision becomes harder.

Not because the product is wrong. But because the information is incomplete.

Fixing that is usually simple.

And it directly improves how your product pages perform.

# Why site navigation needs to follow standard interaction patterns
Source: https://davedavies.dev/reviews/navigation-standard-interaction-patterns/
Published: 2026-03-11

Navigation is one of the most commercially important parts of any online store. If customers cannot browse categories easily, they never reach the product pages where the sale actually happens. This review looks at what happens when a polished main menu breaks down for keyboard users, why that matters commercially, and what established interaction patterns should look like instead.

## Navigation problems appear earlier than most teams expect

Most buying journeys start the same way - regardless of how you browse the web.

A customer arrives on a site and will generally use the main navigation to browse the product categories to see what is available.

If that first step becomes unreliable or even unsable, many customers will simply be stopped right there.

That is what makes navigation issues particularly costly. They do not interrupt an active purchase. They prevent product discovery from happening in the first place.

In the example shown in the video, the menu looks completely fine visually. The dropdown opens, the categories are clearly labelled, and the layout appears tidy.

But when the interaction is tested using a keyboard, the behaviour becomes inconsistent.

## What happens when the submenu opens

The first problem is that when the submenu opens, keyboard focus does not move into it.

Instead of continuing into the newly opened menu, pressing `Tab` moves focus to the next top level navigation item.

So while the submenu is visible on screen, the keyboard user cannot actually enter it in the normal way.

That makes the interaction unpredictable.

It also breaks a basic expectation people have when using website navigation. If a menu opens, they expect to be able to move through the options inside that menu. If that does not happen, the interface starts to feel unreliable.

## Why that happens

In the example in the video above, the submenu exists earlier in the code than the control that opens it.

That means the customer has already technically tabbed past it before having the opportunity to explore it.

So when the menu appears, the only way to reach it is to reverse direction and tab backwards. Most people will not expect that, and many will not realise that is what they need to do.

This is exactly why established interaction patterns matter.

People should not have to work out a custom logic system just to browse a category menu. They should be able to rely on the same predictable behaviour they encounter across other well built sites.

## The second problem: a link acting like a button

The second issue is more subtle, but just as important.

The menu control is coded as a link, but behaves like a button.

That might sound like a small technical distinction, but it changes how the control is understood.

A link is expected to take the user to another page.

A button is expected to perform an action on the current page, such as opening a menu, opening a modal, or submitting a form.

When a control is announced as one thing but behaves like another, the interface becomes harder to understand. Screen readers and other assistive technologies rely on those roles being accurate. More broadly, customers rely on those conventions too, whether they are consciously aware of them or not.

This is not just about technical correctness. It is about keeping the interface understandable at the point where customers are trying to explore what you sell.

## What established interaction patterns actually look like

Established interaction patterns are simply the behaviours customers already expect from navigation because they encounter them on most well built websites.

When a submenu opens, keyboard focus should move into that submenu so the customer can immediately explore the options.

The control that opens the submenu should behave like a button, because it is performing an action on the current page rather than taking the customer somewhere new.

Once inside the submenu, the customer should be able to move through the available options in a logical and predictable order.

And if they decide not to continue, pressing `Escape` should close the menu and return focus to the control that opened it.

Nothing clever or surprising. Just predictable behaviour that lets people browse categories confidently.

## Why this matters commercially

When navigation becomes unpredictable, browsing breaks down.

And if customers cannot reliably browse your categories, they never reach the product pages where they can actually buy.

That makes navigation accessibility a commercial issue, not just a technical one.

You may have strong products, good pricing, solid photography, and a well optimised checkout. But if the path into your catalogue breaks down for some customers at the navigation stage, those strengths do not get a chance to matter.

That is the real risk with interaction problems like this. They interrupt intent before the customer has even reached the page designed to convert them.

For businesses, that means lost discovery, fewer product views, and fewer customers making it into the buying journey at all.

## How to check your own site

You do not need specialist tools to spot this.

Start with your own main navigation and put your mouse to one side.

Then test it like this:

1. Press `Tab` through the main navigation.
2. Open any submenu using the keyboard.
3. Watch where focus goes next.
4. Try moving through the submenu options.
5. Press `Escape` and check whether focus returns to the control that opened the menu.

If focus skips past the submenu, jumps somewhere unexpected, or leaves you unable to explore the category links in a normal way, the navigation is not behaving as customers expect.

That is your signal that the menu needs attention.

## The takeaway

Custom navigation can absolutely work well.

But once you move away from native browser behaviour, you take responsibility for recreating the interaction patterns people already rely on.

In practice, that usually means getting three fundamentals right:

- using the correct control type
- moving focus into opened menus
- keeping the interaction predictable

When those fundamentals are right, navigation feels effortless. Customers can browse categories naturally, understand what is available, and move toward the products they want.

When those fundamentals are missing, some customers will never reach those products at all.

And for an online store, that is not a small usability issue.

It is a missed commercial opportunity happening right at the front door.

# Testing user journeys with browser zoom
Source: https://davedavies.dev/reviews/browser-zoom-testing/
Published: 2026-02-10

## Accessibility review: what happens when page zoom breaks layout and interaction

Browser zoom changes far more than text size. This review looks at how zooming the page affects layout, navigation, and key actions, who it affects, and why layout failures at higher zoom levels can make products harder to buy.

## Testing user journeys with browser zoom

Browser zoom is built into every modern browser and is widely used by customers every day.

It's used by older customers, by people with reduced vision, and by many customers who would not describe themselves as having a disability. It is a practical, built-in way to get more space to compare details, read specifications, or reduce strain after a long day.

In the UK, older demographics hold a disproportionate share of disposable income and wealth, which makes clarity under zoom commercially relevant, not just technically correct.

Unlike changing text size, zoom scales the entire interface. Layout, spacing, fixed elements, and interactive controls all grow together.

This is not niche behaviour. It is a normal way people adapt websites so they can read, understand, and buy without friction.

That scale change quickly reveals whether your layout is resilient or fragile.

Which is exactly why browser zoom is such a valuable thing to test. It's so easy to test - and it takes minutes.

### Browser zoom does more than increase text size

When someone zooms a page, they are not just making text bigger. They are increasing the size of everything on the page, including containers, spacing, and interactive elements.

That scale change puts pressure on the layout.

If a page has only been tested at a single viewport size, that pressure quickly exposes weaknesses. Layouts that looked fine at 100% start to overlap, disappear, or compete for space.

This is where many real-world usability problems start to appear.

### Common issues that appear at higher zoom levels

When reviewing product pages and checkout journeys at higher zoom levels, the same patterns often show up.

Text can overlap or be cut off (or even scroll off the page), making key information harder to read. Sticky headers and footers often take up a disproportionate amount of space, obscuring content beneath them. Navigation menus can become difficult or impossible to reach.

Most importantly, key actions can lose clarity.

Buttons like Add to cart or Continue to checkout might still exist, but their position, visibility, or relationship to the rest of the page becomes less obvious. The action is there, but the path to it is no longer clear.

To a customer, this doesn't feel like an accessibility problem. It starts to feel like the site is broken, and confidence drops.

### Why zoom-related issues matter during checkout

Confidence is fragile during a buying journey.

Customers arrive at a product page with intent. They want to confirm details, choose options, and move forward. Any moment of confusion chips away at that confidence.

When zoom-related layout issues interrupt that flow, most people do not stop to diagnose why. They simply abandon the journey and try another site that feels easier to use.

This is why browser zoom testing is not about edge cases. It is about protecting conversion for customers who are already motivated to buy.

### What a strong zoom experience looks like

Pages that hold together well at higher zoom levels tend to share a few simple characteristics.

**Content reflows instead of overlapping.** Important information remains visible without excessive scrolling. Navigation and menus remain reachable and predictable. Primary actions stay clear and easy to find.

**Nothing complex is required.** The layout is allowed to adapt rather than resist scale.

In the video above, I walk through a strong example of a product page that works well under zoom, alongside a couple that struggle. The contrast makes it clear how small layout decisions can have a big impact on usability.

### A simple check you can do today

You do not need specialist tools to start testing this.

Load one of your product pages. Increase browser zoom. On Windows use `control` and `+` or `-`, and on MacOS use `command` and `+` or `-`. Then slow down and try to read and use the page as if you were seeing it for the first time.

If anything feels awkward, unclear, or frustrating, that experience is not hypothetical. Some of your customers are dealing with it every day.

Browser zoom testing is one of the fastest ways to uncover issues that make products harder to buy.

# Is your custom dropdown costing you customers?
Source: https://davedavies.dev/reviews/accessible-custom-dropdown/
Published: 2025-12-03

## Accessibility review: custom dropdowns on product pages

Many product pages use custom dropdowns for sizes, colours and product options. But what happens when these custom dropdowns only work with a mouse? And what does "fixed" look like for every customer?

## Does your custom dropdown work for _all_ of your customers?

If your dev team or agency are building custom User Interface (UI) components for your website, there’s a good chance they’re replacing perfectly functional browser controls with something that looks polished but works for fewer people. And when that happens, the basic path to purchase breaks.

This is one of the most common

# Are your product options blocking customers from buying?
Source: https://davedavies.dev/reviews/accessible-product-options/
Published: 2025-11-12

## Accessibility review: custom components that break keyboard accessibility

Some of your customers don't use a mouse at all. Here's what happens when your essential product options are clickable but can't be selected with a keyboard - and how this stops people choosing what they want and completing their purchase.

## Are your product options blocking customers from buying?

Product pages often rely on interactive components - grind type, pack size, subscription options, colour choices.

These steps are essential. If someone can't select the option they want, they can't continue.

Most teams assume these components work because **they look correct**. But visual design doesn't guarantee functional design - especially for anyone who shops without a mouse.

### When an option looks clickable but isn't

During testing, one issue comes up again and again: product options built as custom elements.  
They behave like buttons visually, but underneath they're just `div`s with JavaScript attached.

**This isn't necessarily a problem** - but it does mean you need to consider essential keyboard behaviour.

If a mouse click works, but a keyboard press doesn't - then whenever a customer presses **_Tab_** to move through the page it'll skip straight past the essential options.

They try Enter or Space - nothing happens.

The component looks like a choice, but for keyboard and screen reader users it isn't recognised as one.

If someone can't select the options they want, they can't add the product to their cart.

It's not because they're confused - but because the interface doesn't let them participate.

### Why this happens

Modern ecommerce stacks make it easy to create beautiful custom interfaces.
But unless you're careful, these components can lose the built-in behaviour that **real HTML elements** give you:

- real buttons respond to **Enter** and **Space**
- real inputs appear in the **keyboard focus order**
- real labels are **announced by screen readers**
- real components **work consistently** across browsers and devices

Custom components don't get any of that for free.
And so unless a developer rebuilds every behaviour manually, some customers are blocked.

### What this means for your store

If your product options aren't reachable with a keyboard, you have customers who simply cannot buy the item.
They'll try, they'll get stuck, and they'll abandon the page and head to your competitors instead.

You won't see this in your analytics as "accessibility failure".
You'll see it as hesitation, low add-to-cart rates, and unexplained drop-off on pages that should convert well.

### What working options look like

When product options use semantic elements - real buttons, radios, or inputs - everything works automatically:

- customers _can_ select their choice with **Enter** or **Space**
- keyboard users move through options in the _expected order_
- _screen readers announce_ the option name and state
- the "_Add to cart_" button becomes reachable
- everyone gets the same experience, no matter how they browse

**And none of this requires changing your visual design.**
Real buttons and inputs can be styled to match the exact design of your current UI - the difference is that you keep all the built-in behaviour the browser gives you for free.

It's not a complex rebuild.  
It's one of the quickest wins you can make on a product page.

**Try it yourself today:** put your mouse aside and tab through your product page.  
If you can't select an option using your keyboard, some of your customers won't be able to buy from you.

**Accessibility isn't extra.**  
It's how you make sure every customer can choose the product they want - and complete their purchase with confidence.

# Where's your focus? (does your product page break navigation?)
Source: https://davedavies.dev/reviews/wheres-your-focus/
Published: 2025-10-29

When a customer adds something to their cart, the cart drawer slides in - but does the keyboard focus follow? Here's why it matters, and what 'fixed' looks like.

## Where's your focus?

When a customer adds something to their cart, a drawer often slides in from the side ([especially on Shopify stores](https://davedavies.dev/blog/shopify-checkout-accessibility-product-pages/)) - showing their total, a checkout button, maybe a free-shipping message.

**Visually, that's where their attention goes.** But is their keyboard focus there too? In almost every store I've reviewed this month, the answer was **no.**

That means the drawer might be open, but the keyboard user isn't there.

Instead of moving through the cart, the focus stays on the product page, behind the cart - continuing through the normal tab order: size guide, FAQs, returns.

All useful information, **but not where they expected to be.**

They can't reach the checkout button, can't close the cart, and might not even realise the cart is open. It's a small detail that can cause a big disconnect.

The screen reader keeps reading about delivery and returns while the customer thinks, _"hang on, did that even work?"_

### What should happen instead?

When the cart drawer opens, the **keyboard focus should move inside** and stay there until it's closed.

When the user presses **Escape** or clicks away, focus should return neatly to the "Add to cart" button they started from.

That's what "fixed" looks like. And it's a simple fix, too.

A single, seamless movement that makes every customer - visual, non-visual, mouse, or keyboard - feel like the site is working with them, not against them.

👉 **Try it yourself:** add something to your cart using only your keyboard.  
Does your focus move to the drawer - or stay behind?

**Accessibility isn't about adding features.** It's about keeping focus - visual and otherwise - exactly where your customers are.

# What's a keyboard trap? (and why it matters for your online store)
Source: https://davedavies.dev/reviews/keyboard-trap/
Published: 2025-10-17

## Accessibility review: keyboard traps explained

Some customers don't use a mouse to shop. Here's what happens when a keyboard trap stops them from completing their purchase - and why fixing it matters for sales and trust.

## What's a keyboard trap?

You've seen this pattern before. You might even have it on your own ecommerce store.

A promotional modal appears with a tempting offer - 10% off, free shipping, or early access - in exchange for an email address.

**But have you tested if that's where the journey ends?**

Have you tested whether someone can tab **_into_** the form field, but cannot tab **_back out_** again?

Lack of keyboard accessibility was rated the 5th most problematic issue amongst keyboard and assistive technology users.

It's a small frustration. But when small frustrations add up across a site... a missing label here, a confusing form step there... they slowly chip away at trust and patience.

**How many frustrations will you allow, before it's enough to give up and leave?**

In this short video, I show what that experience looks like for keyboard users. A "**_keyboard trap_**" happens when focus gets stuck inside part of a page, like a popup or form, without any way to move forward or back. It's an invisible wall: the interface looks fine, but the customer can't continue their journey.

**Most of the time, this isn't intentional.**

It's just a side effect of custom code or third-party scripts that override normal browser behaviour.

The fix is usually simple. But without testing, it often goes unnoticed.

**You can design a journey that makes people work harder than they should - or one that simply works for everyone.**

**The second one always wins.**

👉 Try it yourself: leave your mouse behind and see if you can move freely through your product pages and all key areas of your site.

If you get stuck, so will some of your customers.

**Accessibility isn't about compliance - it's about people.**

And it's about making sure no customer is left out, no matter how they browse your site.

# Why custom buttons lose customers - and how to fix it
Source: https://davedavies.dev/reviews/pact-coffee/
Published: 2025-05-30

## Accessibility Review: Pact Coffee (Video)

What can Pact Coffee do to remove accessibility barriers and increase their sales? Let's see how their custom buttons are blocking keyboard users.

## How I'd improve Pact Coffee's product page accessibility (and why it matters for conversions)

[Pact Coffee](https://www.pactcoffee.com/) is one of those rare businesses that's genuinely easy to get behind. They roast exceptional speciality-grade beans, delivered straight to your door, and back it all up with a strong ethical mission. They're a certified B Corp, too - so it's clear they care about doing things properly.

But even great businesses can unintentionally lose customers through accessibility barriers across the buying journey - especially in the moments that matter most: choosing a product and completing a purchase.

In this short review video, I walked through Pact's online purchasing experience, to see how well it holds up for users with different access needs - and I found some quick wins here that could significantly boost conversions and customer satisfaction.

### Barrier #1: No visible keyboard focus styles

When navigating Pact's site with the keyboard, there's no visible indication of where I am on the page. I can tab through links and buttons, but there's no visual feedback. Without a visible focus state, keyboard users can easily get lost.

This kind of issue is surprisingly common - fast development cycles often push accessibility down the priority list, and with [94.8% of the top one million websites showing barriers like this](https://webaim.org/projects/million/), it's easy to see how it slips through.

But it matters more than most people realise: **69% of users who encounter an accessibility barrier will abandon the website entirely**. And in the UK alone, [**businesses lose an estimated £17.1 billion a year** due to preventable digital accessibility issues](https://abilitynet.org.uk/news-blogs/research-shows-businesses-lose-17-billion-ignoring-accessibility-needs).

So what would I change?

- **Add visible focus styles.** These can be fully on-brand, and make a huge difference to usability.
- **Clean up the tab order.** Right now, elements that aren't visible (like the cart popover) are still in the tab order, adding confusion.

### Barrier #2: Custom components without native support

Let's pretend for a minute that we're on the Pact coffee dev team, and we've now fixed focus and tab order. Next I want to choose a coffee to start my subscription.

The UI for selecting brew method, grind type, and quantity looks great - but under the hood, it's using non-interactive HTML elements with JavaScript event handlers. These don't receive keyboard focus or screen reader support unless you manually rebuild everything the browser normally provides for free.

And in this case, that hasn't been done.

The result is that **you can't complete a subscription using just a keyboard or screen reader.** That means a paying customer, ready to buy, hits a wall they can't get past.

Here's what I'd recommend:

- Replace decorative `div`s with native HTML elements like `<button>` and `<input type="radio">`.
- Use real radio buttons for brew methods and bag sizes, and native buttons for plus/minus quantity controls.
- Make the quantity editable with a keyboard - not just clickable.

All of this keeps the custom UI intact visually, but ensures that every user can interact with it - not just those using a mouse.

### Why this matters for businesses

This isn't about ticking technical or compliance boxes. It's about accessibility as good business - removing invisible barriers that quietly lose customers and cost revenue.

If someone wants to buy from you but can't - not because of price or product, but because of a hidden UI limitation - that's not just bad UX. That's a missed sale.

And there's a broader pattern here: research shows that [**83% of users with access needs will limit their shopping to websites they know are accessible**](https://abilitynet.org.uk/news-blogs/research-shows-businesses-lose-17-billion-ignoring-accessibility-needs). Meanwhile, **only 8% of disabled users will reach out to report an issue** - the rest just quietly leave and don't come back.

If your site is even _slightly_ easier to use than the competition's, you're not just helping customers - you're earning trust, loyalty, and revenue.

### A competitive advantage in plain sight

Pact already has a brilliant product and a strong mission. A few thoughtful tweaks would make their online experience every bit as good as the coffee they sell.

The best part is these fixes aren't expensive. They don't require a redesign. They're focused, high-impact improvements that make the buying process smoother for everyone.

And if you're thinking long-term: digital accessibility isn't just the ethical choice - it's a [**real competitive edge in a world where 96% of websites still have detectable accessibility issues**](https://wearepurple.org.uk/the-purple-pound-infographic/).

So here's the opportunity: remove invisible barriers, grow your customer base, and make the checkout experience as inclusive as the business itself.

# Are accessibility widgets useful?
Source: https://davedavies.dev/reviews/passenger/
Published: 2025-05-01

## Accessibility Review: Passenger Clothing Website (Video)

What can Passenger Clothing do to remove accessibility barriers and increase their sales? Let's take a look how I'd improve Passenger Clothing.

[Passenger Clothing](https://www.passenger-clothing.com) is one of my favorite ecommerce companies. They're sustainably led, they have great products, and they're clearly passionate about what they do.

Recently, while browsing their website, I noticed they've added an accessibility widget in the footer so I decided to take a closer look at how it performs. **Here's how I'd improve it to help Passenger reduce abandonment and increase sales.**

## How accessibility issues hurt your revenue

Accessibility isn't just about being socially responsible - it's a powerful way to **increase conversions** and directly impact your bottom line. [A recent UK report reveals that 69% of customers who encounter accessibility barriers will leave a website and not return](https://www.clickawaypound.com/). That's **costly abandonment** and lost revenue walking out your digital front door. And with **£17.1 billion lost every year due to inaccessible websites**, let's look at how Passenger can avoid being part of that.

## Why accessibility overlays aren't solving the real problem

Passenger's accessibility widget offers features like:

- Larger text options
- Cursor enlargement
- Line height adjustments
- Font variations

For customers who need these features, they sound incredibly helpful in theory. However, modern browsers like Firefox, Chrome, and Safari already include these features.

And here's the thing - the browser usually does a better job than third-party widgets.

Most customers who will benefit from using these assistive technologies already have their systems set up in a way that works for them. So while the intention is good, these widgets often create an extra layer of complexity rather than improving the overall experience for your customers.

## Real user experience: friction that drives customers away

To understand the real user experience, I tested both the widget and browser features. When using the widget's text enlargement and navigating between pages, I noticed a significant delay as the widget tried to "catch up" with the page load.

This layout shift can be quite jarring if it's the first time you encounter this. And even if you are expecting this behavior, it's still quite a frustrating experience.

**These friction points matter**.

[The Baymard Institute found that 23% of customers abandon checkout when the process feels too confusing or difficult](https://baymard.com/lists/cart-abandonment-rate). Accessibility issues absolutely contribute to this abandonment rate - whether it's slow-loading pages, unclear navigation, or **costly UX barriers that frustrate customers and reduce sales**.

## How good UX doubles as accessibility

In contrast, using the browser's built-in zoom functionality was seamless. Passenger's responsive design handles browser zoom beautifully, maintaining perfect functionality even at 200% zoom.

The navigation feels intentional, and that's because it is. There's no lag, no jumping elements, just a smooth adaptation to the user's needs.

This demonstrates something powerful: when you invest in good responsive design, you not only create a more inclusive experience - you also **optimise for all customers**, making your site faster, clearer, and more profitable.

## A clear path to more sales (without rebuilding your site)

Here's what impressed me most about Passenger: they clearly care. Adding an accessibility widget shows they're thinking about inclusion and trying to do the right thing. But they don't need the widget. With just a few focused adjustments, they could **reduce cart abandonment, unlock more revenue**, and deliver a better experience to all customers.

Now - this is surprisingly common. In fast-paced ecommerce environments, accessibility considerations often slip through the cracks. But this isn't about blame - it's about the opportunity.

## Remove accessibility barriers, win more customers

Consider this: [96% of websites currently have detectable accessibility issues on their homepage](https://webaim.org/projects/million/)

By addressing even a portion of these issues, you're immediately outperforming most of the internet. And removing accessibility barriers isn't just the right thing to do - it's one of the easiest **growth opportunities in your checkout** and a legitimate competitive advantage.

When you improve accessibility, you:

- Reduce customer abandonment
- Increase your addressable market [(with a collective spending power of £25 billion in the UK alone)](https://reciteme.com/news/six-key-points-from-the-click-away-pound-survey-2019/)
- Improve the experience for ALL customers
- Build brand loyalty among appreciative customers

## Moving forward

The goal here isn't perfection - it's progress.

Focus on removing barriers that prevent customers from completing their purchases - **fixing these friction points is key to increasing conversions and long-term loyalty**. Test your checkout flow, navigation, and core customer journeys to identify and fix the issues that might be costing you sales.

Remember: inclusive design is good business. Every barrier you remove is a potential customer retained.