Autonomics AI
Menu

Accessibility quick wins for a small business website

Ten checks you can run on your own site in an afternoon, with free tools. They catch many of the problems that stop people who use screen readers, keyboards or zoom from using a small business website. They won't make a site fully accessible on their own, and nobody can promise you legal compliance from a checklist.

Written by Sean Solano Paul, founder of AutonomicsAI LLP. Published .

Before you start

You need a browser and about an afternoon. Three free tools help: WAVE from WebAIM, the Lighthouse accessibility report built into Chrome's developer tools, and the axe DevTools browser extension. Automated tools find only some problems. Several checks below have to be done by hand, and those are often the ones that matter most.

The standard behind all this is the W3C's Web Content Accessibility Guidelines (WCAG) 2.2. The numbers in brackets point to the relevant part.

The ten checks

  1. Every image that means something has a description

    Product photos, before-and-after shots and diagrams need alt text that says what's in them ("Replaced asphalt shingle roof on a two-storey house"). Decorative images get an empty alt="" so screen readers skip them. Don't start with "image of". (1.1.1)

    Test: WAVE flags images with no alt text. Then read the alt text you do have: "IMG_2041.jpg" counts as missing.

  2. Every form field has a visible label

    A label above the field, connected to it in the code, not grey placeholder text inside it. This is the most common problem we find on quote and contact forms. (1.3.1, 3.3.2)

    Test: click on the label text. If the cursor doesn't jump into the field, it isn't connected.

  3. Text is dark enough against its background

    Normal text needs a contrast ratio of at least 4.5 to 1, and large text at least 3 to 1. Light grey text on white is the usual failure, and so is white text over a photo. (1.4.3)

    Test: Lighthouse and WAVE both report it. WebAIM also has a free contrast checker where you paste two colours.

  4. You can use the whole site with only a keyboard

    Press Tab to move through the page. Every link, button and form field should be reachable, in a sensible order, and you should be able to open menus and send forms with Enter or Space. (2.1.1)

    Test: by hand. Put the mouse away and try to send your own quote form.

  5. You can see where you are while tabbing

    Whatever has keyboard focus needs a visible outline. Many themes remove it because someone thought it looked untidy. (2.4.7)

    Test: by hand, during the keyboard check.

  6. Headings are real headings, in order

    One main heading (h1) per page, then h2s for sections, h3s inside those. Screen reader users jump between headings the way you skim. Big bold text that isn't marked up as a heading doesn't count. (1.3.1)

    Test: WAVE's "Structure" tab shows the heading outline.

  7. Links say where they go

    "Click here" and "Read more" repeated five times tell a screen reader user nothing when they list the links on a page. "See our roof repair prices" does. (2.4.4)

  8. The page language is set

    One attribute, lang="en" on the page, tells screen readers which pronunciation to use. It's often missing on hand-built and older sites. (3.1.1)

    Test: Lighthouse reports it.

  9. The page works when zoomed to 200%

    Zoom the browser to 200%. Text should grow without being cut off or overlapping. WCAG goes further and asks that a page still reads without sideways scrolling at 400% zoom on a normal screen. (1.4.4, 1.4.10)

    Test: by hand, Ctrl and + (or Cmd and + on a Mac).

  10. Buttons and links are big enough to tap

    WCAG 2.2 added a minimum target size: 24 by 24 CSS pixels, or enough space around smaller targets. For anything people tap often, like a call button, we aim for 44 pixels. (2.5.8)

    Test: by hand on a phone. If you tap the wrong link next to the one you wanted, it's too small.

What to fix first

Start with whatever stops someone from contacting you or paying you: the quote or contact form (labels, keyboard, focus), then the phone number and booking button, then everything else. A fully accessible About page doesn't help if the form can't be sent with a keyboard.

What this checklist won't do

  • It isn't a full audit against WCAG 2.2, and passing it doesn't mean your site meets any law or standard.
  • Accessibility overlay widgets (a script that adds a toolbar to your site) don't change the code underneath, which is where these problems live. We don't recommend them as a fix.
  • If you've received a legal demand about your website, talk to a lawyer, not a checklist.

Related: our fixed-price accessibility fix sprint.