A Practical Website Accessibility Audit for Small Businesses

Why accessibility belongs on your to-do list

Most small business owners think about accessibility only after they hear the word in a legal context. That is understandable, but it frames the topic backwards. Accessibility is simply the question of whether people can use your website. Some visitors navigate with a keyboard because of a motor impairment or a broken trackpad. Some use screen readers. Some have low vision, colour blindness, or a migraine that makes a busy page painful. Some are on a cracked phone screen in bright sunlight. Many are older customers who increase text size.

When your site works for these visitors, it tends to work better for everyone. Clear headings help people scan. Good contrast helps on cheap monitors. Labelled form fields reduce errors for every user. Accessibility improvements are usability improvements with a moral and practical case attached.

The widely used reference is the Web Content Accessibility Guidelines (WCAG), published by the W3C. You do not need to memorise them. You need a repeatable way to find the most common barriers and remove them. That is what this audit is for.

Accessibility is not about a perfect score. It is about removing the barriers that stop real people from finishing real tasks.

Before you start: pick your pages and tasks

Do not try to audit every page at once. Choose a small, representative set:

1. Your homepage.
2. One core service or product page.
3. Your contact, booking or checkout flow.
4. A blog post or article.
5. Any page with a form, a pricing table or an embedded video.

Then write down the three to five tasks that matter most to your business. For a service firm that might be "find out what we offer", "see pricing or how pricing works", and "book a call". For a shop it might be "find a product", "choose a size" and "pay". You will test these tasks end to end, because a page can look fine in isolation while the journey still breaks.

Keep a simple spreadsheet with columns for page, issue, who it affects, severity (blocks task, slows task, cosmetic), and fix. This becomes your work list.

Check 1: The keyboard test

This is the single most revealing test, and it is free. Put your mouse aside and use only the keyboard.

• Tab moves forward through links, buttons and form fields.
• Shift + Tab moves backward.
• Enter activates links and buttons; Space toggles checkboxes and activates buttons.
• Arrow keys move within menus, radio groups and sliders.
• Escape should close pop-ups and menus.

As you move through the page, ask:

1. Can I always see where I am? There should be a visible focus indicator, such as an outline or highlight, on whatever is selected. Many themes remove it for visual reasons. That leaves keyboard users lost.
2. Is the order logical? Focus should follow the visual reading order, top to bottom and left to right for most languages.
3. Can I reach everything? Menus, dropdowns, accordions, tabs, sliders and "read more" toggles should all work with the keyboard.
4. Can I get out? Pop-ups, chat widgets and cookie banners sometimes trap focus or cannot be closed without a mouse.
5. Is there a skip link? On pages with long menus, a "skip to main content" link that appears on first Tab saves a lot of effort.

Common fixes include restoring the focus outline in CSS, replacing clickable div elements with real button or a elements, and making sure modals move focus inside when they open and return it when they close.

Check 2: Colour and contrast

Low contrast text is one of the most frequent accessibility failures on the web. Light grey text on white, white text on a pale photo, and thin fonts on coloured backgrounds all cause trouble.

WCAG sets contrast ratios: for normal body text the commonly cited target is at least 4.5:1, and for large text at least 3:1. Interface elements such as input borders and icons also need sufficient contrast against their background. You can measure these with free tools like the WebAIM Contrast Checker or the contrast information in your browser's developer tools.

While checking contrast, also look for colour-only meaning:

• Required form fields marked only in red.
• Error states shown only by a red border.
• Charts and status badges that rely only on colour.
• Links within body text distinguished only by colour, with no underline.

Add a second signal: an icon, a word, an underline or a pattern. This helps colour-blind visitors and anyone viewing on a poor screen.

Check 3: Headings and page structure

Screen reader users frequently navigate by headings, jumping from one to the next to understand the page. Sighted users scan headings too. A sound structure looks like this:

• One H1 that describes the page.
• H2 headings for main sections.
• H3 headings for subsections within those.
• No skipped levels purely for visual size.

Many sites use heading tags to make text big, or use bold paragraphs where headings belong. Both confuse assistive technology. Browser extensions such as HeadingsMap, or the accessibility panel in developer tools, show your heading outline quickly. If the outline does not read like a sensible table of contents, it needs work.

Also check landmarks: the header, navigation, main content and footer should use the right HTML elements (header, nav, main, footer). These let screen reader users jump directly to the part they need.

Check 4: Images, icons and media

Every meaningful image needs a text alternative that conveys its purpose. Every purely decorative image should be marked so that screen readers skip it.

Practical rules:

• Informative images (a photo of your team at work, a product image): describe what matters in context. "Technician installing a wall-mounted router in a small office" is more useful than "image1.jpg" or "photo".
• Functional images (an icon that is a link or button): describe the action, not the picture. A magnifying glass icon that opens search should be labelled "Search".
• Decorative images (background textures, dividers): use an empty alt attribute (alt="") so they are ignored.
• Images of text: avoid them. If unavoidable, the alt text should contain the same words.
• Charts and infographics: provide a short summary nearby and the key data in text.

For video, provide captions. Auto-generated captions are a starting point, not a finished product; review them for names and technical terms. For audio-only content such as a podcast, provide a transcript. Avoid autoplaying video with sound, and give users a way to pause any motion that lasts more than a few seconds.

Check 5: Forms

Forms are where accessibility problems cost you money directly, because a blocked form is a lost lead or sale. Test every form you rely on.

• Labels: every field needs a visible label that is programmatically connected to it. Placeholder text alone disappears when you type and is often low contrast.
• Instructions: explain format requirements before the user makes a mistake, for example "Phone number, including area code".
• Errors: when something goes wrong, say what and where in text, near the field, and move focus or announce the error so screen reader users know.
• Required fields: mark them in text, not only with colour or an asterisk without explanation.
• Autocomplete: use the right autocomplete attributes for name, email, address and phone. This helps everyone, especially people with motor or memory difficulties.
• Captchas: puzzle-style captchas can block people. Consider less intrusive spam protection.
• Time limits: avoid sessions that expire quickly during checkout or long forms, or warn and allow extension.

Fill out each form using only the keyboard, then again with a screen reader if you can. On Windows, NVDA is free; on Mac and iPhone, VoiceOver is built in; on Android, TalkBack is built in.

Check 6: Text, zoom and responsive layout

Increase your browser zoom to 200 percent and see what happens. Text should get bigger without overlapping or being cut off, and you should not have to scroll sideways to read paragraphs. Then try the page on a narrow phone screen.

Also check:

• Font size: body text that is very small or very thin is hard for many readers.
• Line length and spacing: very long lines and cramped spacing make reading tiring.
• Link text: "Click here" and "Read more" repeated many times give no context out of order. Prefer "Read our website maintenance guide".
• Language: the page should declare its language in the HTML so screen readers pronounce words correctly.
• Plain language: jargon, long sentences and dense paragraphs are barriers too. Clear writing is an accessibility feature.

Check 7: Motion, pop-ups and interruptions

Animated backgrounds, parallax scrolling, carousels that move on their own and sudden pop-ups can disorient people, trigger vestibular symptoms or simply make tasks harder.

• Respect the operating system's "reduce motion" setting with the prefers-reduced-motion media query.
• Give carousels pause controls, or replace them with static content.
• Delay or limit pop-ups, and make sure they can be closed with the keyboard and announced to screen readers.
• Never use flashing content.

Check 8: Run an automated scan, and read it critically

Automated tools are useful for finding repeatable problems at scale: missing alt attributes, empty buttons, low contrast, missing labels and invalid ARIA. Good free options include WAVE from WebAIM, the axe DevTools browser extension, and the accessibility audit in Lighthouse within Chrome developer tools.

Two cautions:

1. They cannot judge meaning. A tool can see that alt text exists, but not whether it makes sense.
2. A high score is not a guarantee. Treat the score as a pointer to issues, not proof of accessibility.

Run the scan on each page in your sample, add the findings to your spreadsheet, and de-duplicate. You will often find that one template issue, such as a missing label in the site-wide newsletter form, appears on every page and can be fixed once.

A note on overlays and "one-line fixes"

You may see products that promise instant compliance by adding a script to your site. Be careful. Many accessibility practitioners and disabled users have criticised overlay tools for not fixing the underlying code and sometimes interfering with the assistive technology people already use. Fixing the actual HTML, CSS and content is the reliable route. If a vendor promises a guarantee, ask exactly what they change and how it is tested.

Prioritising what to fix

With your spreadsheet filled in, sort issues into three groups:

Fix now (blocks tasks)

• Forms that cannot be completed by keyboard or screen reader.
• Navigation menus that cannot be opened without a mouse.
• Pop-ups that trap focus.
• Checkout or booking steps that fail.
• Critical text with very low contrast.

Fix soon (slows or confuses)

• Missing or poor alt text on key images.
• Broken heading structure.
• Vague link text.
• Missing captions on important videos.

Improve over time

• Plain language rewrites.
• Motion reduction.
• Consistency across older blog posts.

Assign owners and dates. Template-level fixes (header, footer, forms, product cards) usually deliver the biggest improvement for the least effort, because they affect every page.

Making accessibility part of publishing

An audit is a snapshot. New pages, plugins and campaigns will introduce new issues unless accessibility becomes part of your routine. A few habits help:

• Add an alt text field check to your blog and product publishing checklist.
• Use the heading styles built into your editor rather than manual bold text.
• Check contrast when choosing brand colours and campaign graphics.
• Test new forms with the keyboard before launch.
• Re-run an automated scan monthly and a manual keyboard test quarterly.
• Publish an accessibility statement with a contact method so visitors can report problems, and respond when they do.

Quick audit checklist

Copy this list into your project notes:

• [ ] Focus is visible on every interactive element.
• [ ] All menus, buttons and forms work with the keyboard alone.
• [ ] Pop-ups and banners can be closed with Escape and do not trap focus.
• [ ] Body text meets contrast guidance; links are distinguishable without colour alone.
• [ ] One H1 per page and a logical heading outline.
• [ ] Landmarks (header, nav, main, footer) are present.
• [ ] Meaningful images have useful alt text; decorative images use empty alt.
• [ ] Every form field has a visible, connected label.
• [ ] Errors are described in text and announced.
• [ ] Page works at 200 percent zoom and on small screens.
• [ ] Videos have reviewed captions; audio has transcripts.
• [ ] Motion respects reduced-motion settings.
• [ ] Automated scan run and findings reviewed manually.
• [ ] Accessibility statement and contact method published.

Frequently asked questions

Do small businesses really need to worry about accessibility? Yes, for practical reasons first: you want every potential customer to be able to use your site. Legal expectations vary by country and sector, and they have been expanding, so if you have specific compliance questions, speak with a qualified legal adviser in your jurisdiction.

Which WCAG level should I aim for? Many organisations use WCAG 2.1 or 2.2 Level AA as their working target, because it covers the most impactful issues without the stricter requirements of AAA. It is a sensible goal for most business sites.

Can my theme or page builder be accessible? Often, yes, but quality varies. Test the theme's menus, forms and focus styles before committing. Sometimes a few template fixes make an existing theme acceptable; sometimes rebuilding key components is cheaper in the long run.

How long does an audit take? For a small site with a sample of five pages, the manual checks above usually take a few hours. Fixing depends on how many issues are template-level versus page-level.

Should I hire a specialist? If your site handles bookings, payments or regulated services, a professional review plus testing with assistive technology users is worthwhile. For a simple brochure site, a careful owner-led audit followed by targeted developer fixes is a strong start.

How we can help

We build and maintain websites with accessibility in the foundations: semantic HTML, keyboard-friendly components, readable design and forms that work for everyone. If you want an audit of your current site or a redesign that gets the basics right, see our business website development and website redesign services, browse our solutions, or book a discovery call.