Website accessibility checklist for small businesses and shops

Picture a customer who uses a screen reader. They find the trainers they want, pick a size, and press what they think is the basket button. Their screen reader says “button”. Nothing else. There are three of those on the page and none has a name, so they leave, and you never find out why.

Most accessibility problems on small business sites look like that: invisible to the owner, a dead end for the customer. This checklist is for people running a Shopify, WooCommerce, Wix or Squarespace site without a developer on staff.

Does my small business website need to be accessible?

If you sell to consumers in the EU, probably yes. The European Accessibility Act (opens in a new tab) has covered e-commerce services since 28 June 2025. The main exemption is for microenterprises that provide services: businesses with fewer than 10 staff and an annual turnover or balance sheet total of no more than €2 million.

E-commerce here means selling at a distance, through a website or app, “at the individual request of a consumer with a view to concluding a consumer contract” (Article 3(30)). An online shop or a booking engine fits. The exemption covers services only: selling covered products such as e-readers still brings product rules (Article 4(5)). Being outside the EU doesn't help either, because a UK shop selling to customers in France is covered for them (Article 3(4)). Our guide to the European Accessibility Act covers national laws and fines.

The UK's Equality Act 2010 (opens in a new tab) requires reasonable adjustments for disabled people but sets no technical standard for websites. In the US, the Department of Justice's March 2022 guidance (opens in a new tab) says businesses open to the public must make what they offer online accessible, and that standards such as WCAG “provide helpful guidance”. Whatever the law says, a customer who can't finish your checkout doesn't buy.

What are the most common accessibility problems on websites?

Six failures dominate. In the WebAIM Million 2026 (opens in a new tab), an automated scan of the top one million home pages in February 2026, 95.9% of pages had detected WCAG failures, with an average of 56.1 errors per page. Low-contrast text was the most common problem, found on 83.9% of home pages.

WCAG, the Web Content Accessibility Guidelines, is the standard behind these checks; most laws point to its Level AA, and our guide to WCAG 2.2 explains the latest version. Several checks below are things no scanner can judge.

Can everyone read your text and understand your images?

Start here, because these fixes are cheap and mostly yours to make in the site editor. Text needs enough contrast, images that carry information need alt text, and nothing should rely on colour alone. About 1 in 12 men and 1 in 200 women have a colour vision deficiency, according to Colour Blind Awareness (opens in a new tab).

• Contrast. Normal text needs a contrast ratio of at least 4.5:1 (opens in a new tab) against its background, large text at least 3:1. Test your colours, including text over banner photos, in a free checker. Our colour contrast guide shows fixes that keep your brand.
• Product alt text. Describe what a shopper needs to know: “Navy wool jumper with a ribbed roll neck, front view” beats “product image 1”. Start with your ten best sellers.
• Decorative images. A background swirl should have empty alt text so screen readers skip it. Some platforms fill a blank alt field with the file name, so check yours.
• Colour alone. “Out of stock” shown only as a greyed-out swatch, or a required field marked only in red, won't reach everyone. View the page with your phone's greyscale filter and add a word or icon wherever meaning disappears.
• Zoom. At 200% browser zoom, text should grow without overlapping or being cut off, and the menu should still work.
• Page language. Any free checker flags a missing language declaration. It's a theme setting or a one-line template change.

Can people use your site with a keyboard?

Plenty of people browse without a mouse: screen reader users, people with a tremor or limited hand movement, and anyone whose trackpad has just died. Put your mouse aside and press Tab. You should reach every link, button and form field in a sensible order, always see where you are, and never get stuck.

• Visible focus. An outline should show which element is active, and a sticky header or chat bubble mustn't cover it (WCAG 2.2's 2.4.11 Focus Not Obscured). Many themes remove the outline for looks; a developer can restore it.
• No traps. Open the menu, size picker, pop-ups and image gallery from the keyboard, choose something, then try to leave. Escape should close pop-ups.
• Names for icons. Every icon link and button needs a name a screen reader can announce, such as “Basket, 2 items”. Replace “Click here” with words that say where the link goes.
• Skip link and headings. The first Tab press should ideally reveal a “Skip to content” link. In WebAIM's 2024 screen reader survey (opens in a new tab), 71.6% of respondents said they first navigate a long page by its headings, so use real heading levels, not bold text.
• Tap targets. WCAG 2.2 asks for targets of at least 24 by 24 CSS pixels, or enough space around them (success criterion 2.5.8 (opens in a new tab)).

Can everyone get through your forms, cart and checkout?

Checkout is where accessibility problems cost you money directly, so test it from start to finish, including what happens when something goes wrong. Every field needs a visible label, errors must explain the problem in words, and logging in shouldn't depend on memory tests or puzzles. Your payment provider's pages count too.

• Labels, not placeholders. Placeholder text vanishes as soon as someone types and is often too pale to read. Each field needs a label that stays visible.
• Error messages. Submit the form empty. Each error should be written out (“Enter a postcode, for example SW1A 1AA”), sit next to its field and be announced, not just turn a border red.
• Don't ask twice. Offer “Billing address is the same” rather than making people retype their delivery address. WCAG 2.2 made this a Level A requirement, 3.3.7 Redundant Entry.
• Logging in. Let people paste passwords and one-time codes and use password managers. Blocking paste fails WCAG 2.2's Accessible Authentication criterion (opens in a new tab) unless you offer another way in.
• CAPTCHAs. Screen reader users ranked CAPTCHA the most problematic item on the web in WebAIM's 2024 survey. If you need bot protection, avoid visual puzzles and always offer a non-visual alternative.
• Time limits. If a basket or booking hold expires, warn people and let them extend it.

If parts of the checkout belong to your platform or payment provider, test them anyway, report problems and list them as known issues.

What about cookie banners, pop-ups and chat widgets?

To your customers, third-party scripts are part of your website. A cookie banner that can't be closed with a keyboard blocks every page, and a newsletter pop-up that grabs focus mid-checkout can stop a sale. Test every script you've added, and ask vendors about accessibility before you install a new one.

• Cookie banner. Can you reach accept and reject with Tab, read them at 200% zoom, and carry on where you were afterwards?
• Pop-ups. Focus should move into the pop-up, stay there until it closes, then return. Escape should close it.
• Chat widgets. The button needs a name, the window should open and close from the keyboard, and on a phone it shouldn't sit on top of “Pay now”.
• Carousels. Anything that moves automatically for more than five seconds needs a way to pause, stop or hide it (WCAG 2.2 (opens in a new tab), success criterion 2.2.2).
• Embeds. Review widgets, maps and booking tools sit on your page too. Raise failures with the supplier.

Do your videos, PDFs and menus work for everyone?

Video needs captions, audio needs a transcript, and important information shouldn't live only in a PDF or an image. A restaurant whose menu is a scanned PDF, or a shop whose size guide is a photo of a table, shuts out screen reader users and anyone who needs to zoom in on a phone.

• Captions and transcripts. Correct automatic captions before publishing. Podcasts need a text version.
• Pictures of text. Put menus, price lists, size guides and opening hours on an ordinary web page. If you must use a PDF, export it with headings and tags from your word processor rather than scanning a printout.
• Older files. The EAA doesn't require you to fix office files or pre-recorded audio and video published before 28 June 2025, or archives you no longer update (Article 2(4)). New files are in scope.

What can I fix myself, and when do I need a developer or an audit?

You can fix most content problems yourself in the CMS: alt text, headings, link text, colours, captions and many form labels. Theme-level problems such as missing focus styles, keyboard traps and custom drop-downs need a developer. An audit makes most sense once the basics are fixed, or before a redesign goes live.

Where does a widget like ours fit? A visitor-side panel such as SiteAccessible lets people raise contrast, enlarge text or switch on a reading guide. That helps some visitors, but it doesn't tick off anything on this checklist: an unnamed button stays unnamed and a keyboard trap stays a trap. Fix the site first and treat a widget as an extra.

How do I record what I've done?

Keep a simple log of what you tested, when, what you fixed and what's still broken, then publish an honest summary in an accessibility statement. If the EAA applies to you, you also have to publish information on how your service meets the accessibility requirements, usually in your terms and conditions or an equivalent document.

That second duty comes from Annex V of the directive; national law sets the format. Our guide to writing an accessibility statement includes a template you can adapt. Then keep the routine going:

1. Run the checklist on your three key pages and screenshot every failure.
2. Fix the content items yourself this week.
3. Brief a developer on the theme and checkout items, worst first.
4. Re-test each fix with a keyboard as well as a checker.
5. Publish or update your statement, with the date.
6. Repeat whenever you add an app, change theme or launch a new landing page.