Most accessibility problems on small business websites are not hard to fix. They are hard to notice, because the people who build and approve a site tend to use it with a mouse, good eyesight, a large screen and no hurry. The visitor on a keyboard, with a screen reader, or on a phone in bright sun meets a different site.
Seven basics follow, each with a five-minute check you can run in an ordinary browser. No specialist or paid tool required.
Real headings, in order
Screen reader users often move through a page by its headings, the way everyone else skims. That works only when the headings are real h1 to h6 elements in order: one h1 for the page, h2 for its sections, h3 inside those. Bold text styled to look like a heading is not one, and neither is a heading level picked because its size looked right.
Check: open the developer tools (F12), go to the Console, paste this and press Enter. The browser may ask you to type "allow pasting" first.
document.querySelectorAll('h1, h2, h3, h4, h5, h6')
.forEach(h => console.log(h.tagName, h.textContent.trim()));Read the output as a table of contents. If it skips levels, has two h1s or misses a section you can see, fix the markup and restyle with CSS.
Alt text that says something
Alt text is what a screen reader reads in place of an image. It should say what the image is there to tell the visitor. A photo of your entrance on a "how to find us" page might be "Ground-floor entrance beside the pharmacy, with a ramp". Not "image", not the file name, not a string of keywords. A purely decorative image gets an empty alt="" so it is skipped. And opening hours on a poster or a price list saved as a picture are not text to anyone who cannot see them: put them on the page as real text.
Check: a Lighthouse report (in Chrome's developer tools, Accessibility category) lists images with no alt attribute. It cannot judge the rest, so right-click a few images, choose Inspect, and read each alt without looking at the picture. If it tells you nothing, rewrite it.
Colour contrast you can read
Pale grey text on white looks refined in a design file and disappears on a phone outdoors. The Web Content Accessibility Guidelines (WCAG) ask for a contrast ratio of at least 4.5 to 1 for body text and 3 to 1 for large text. Text over photographs is the usual trouble spot.
Check: right-click some light text, choose Inspect, and click the small colour swatch next to the text's colour in the Styles pane. Chrome shows the ratio and whether it passes. Look hardest at footers, buttons and form placeholders, where light grey tends to live.
Forms with labels
Placeholder text inside a box is not a label: it vanishes as soon as someone types. A visible label tied to its field tells a screen reader what the field is for, and gives everyone a bigger target to click:
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">Errors need the same care. "Invalid input" helps nobody. Name the field and say what is wrong: "Enter your phone number, including the area code".
Check: click the words beside each field. If the cursor jumps into the field, the label is connected. If nothing happens, it is not.
Everything works from the keyboard
Some visitors cannot use a mouse. A keyboard user moves with Tab and Shift+Tab, follows links with Enter, presses buttons with Enter or Space, and closes things with Escape. Real links and real button elements get all of that for free. A div with a click handler gets none of it, which is how menus, sliders and cookie banners end up with no way in.
Check: put the mouse out of reach and do the one thing the site exists for: send an enquiry, book an appointment, place an order. Wherever you get stuck, a keyboard user is stuck too, and they will not ring to tell you.
Focus that stays visible
Tabbing is useless if you cannot see where you are. Browsers draw an outline around the focused element, and one line of CSS, outline: none, usually added because the outline looked untidy after a click, leaves keyboard users working blind. Style the outline instead of deleting it. :focus-visible shows it to keyboard users without drawing it on every click:
a:focus-visible,
button:focus-visible,
input:focus-visible {
outline: 3px solid #1d4ed8;
outline-offset: 2px;
}Check: during the keyboard test, watch the screen at every Tab press. If the highlight vanishes even once, search the stylesheets for outline: none and outline: 0.
Not relying on colour alone
Some people cannot tell red from green, and bright sun washes colour out of every phone screen. Required fields marked only in red, errors shown only as a red border, links that differ from the surrounding text only in colour: each needs a second signal, such as the word "required", an error message in words, or an underline. Picture a chartered accountancy firm's deadline calendar with overdue dates in red. Add the word "overdue" and it works for every visitor.
Check: in Chrome's developer tools, open the Rendering panel (three-dot menu, More tools) and emulate a vision deficiency. Achromatopsia shows the page with no colour at all. Anything you can no longer tell apart needs a second signal.
Start with the page that brings in work
Run all seven checks first on the page that matters most, usually the contact or booking page, then the home page, then the rest. None of this makes a site fully conformant with WCAG, and it is no substitute for watching someone who relies on a screen reader try your site. It does catch the problems that turn up most often, and behind each of them is a visitor who wanted to get in touch and gave up.
