Small-business website accessibility:a practical owner’s audit.

01 · Set the right expectation

A first-pass audit finds barriers; it does not certify a site

W3C's Easy Checks are intentionally a starting point. A page can appear to pass those checks and still contain significant barriers. Likewise, evaluation tools can identify missing labels, contrast failures, and other testable problems, but W3C states that tools cannot determine accessibility on their own. Human judgment is still required.

That distinction protects the business from false confidence. An automated result may confirm that an image has analt attribute without deciding whether the text communicates the image's purpose. A scan may find a form field label without proving that the error message is understandable after a failed submission.

Use this audit to create a prioritized improvement list. A full standards evaluation or legal-compliance assessment is a separate scope and should not be promised by a score, plugin, or single test session.

02 · Start where value is created

Choose one real customer path before opening a checker

Begin with the action the website is supposed to support. For a contractor, that may be reading a service page and requesting an estimate. For a salon, it may be checking services and opening a booking flow. For a restaurant, it may be finding the current menu, hours, location, and phone number.

1. Step 01
   Name the task in plain language.

   “Request an estimate” is more useful than “audit the website.” It creates a clear beginning and completion.

2. Step 02
   List every page and handoff in the path.

   Include menus, service pages, contact forms, maps, booking tools, and confirmation states on other domains.

3. Step 03
   Test the path in more than one way.

   Use a keyboard, zoom the page, try a phone, and submit both valid and invalid information.

A path-based audit keeps priorities tied to customers. A minor issue on an old announcement page may matter less than an unlabeled required field that blocks every estimate request.

03 · Put the mouse aside

Can a customer navigate and act with a keyboard?

Load the page, set the mouse aside, and use the Tab key to move through interactive elements. Use Shift+Tab to move backward, Enter to follow links, Space where appropriate, and Escape to close menus or dialogs when that behavior is expected.

• Focus appears in a logical order that follows the page.
• Every link, button, menu, form field, and modal can be reached.
• The current focus is clearly visible against its surroundings.
• Focus does not become trapped inside a menu, widget, or dialog.
• A skip link lets keyboard users move past repeated navigation.
• Opening or closing a component does not make focus disappear.

W3C's Easy Checks call out visible keyboard focus because people who navigate with a keyboard need to know which control is active. WCAG 2.2 also requires keyboard-operable functionality, with limited exceptions for input that depends on the path of movement itself. The practical test is simple: if the inquiry path requires a mouse, it is not ready.

04 · Make the page understandable

Use page titles and headings as a reliable outline

A clear browser title helps a visitor understand which page is open. A descriptive main heading confirms the subject once the page loads. Subheadings then break the content into sections that can be scanned visually or navigated with assistive technology.

This is not a keyword-stuffing exercise. W3C notes that clear, descriptive headings help people find information and understand relationships between sections. Write the outline for the customer first; the cleaner structure also gives search systems more useful context than a pile of vague labels.

05 · Protect the inquiry

Labels, instructions, errors, and success messages all matter

A contact or booking form is often the most important conversion point on a small-business website. Placeholder text inside a field is not a dependable substitute for a visible, programmatically associated label. The placeholder can vanish as soon as someone begins typing, taking the instruction with it.

• Every field has a persistent, descriptive label.
• Required fields are identified before submission.
• Expected formats or constraints appear before the field is completed.
• Related options such as radio buttons are grouped and named clearly.
• Errors identify the affected field in text, not by color alone.
• Error guidance explains what needs to be corrected.
• A successful submission produces an understandable confirmation.

Test the form twice: once with valid information and once with a required field missing or an invalid format. W3C's forms guidance recommends notifying users about both successful task completion and errors, with instructions that help them recover. The same clarity helps everyone finish the inquiry with less uncertainty.

06 · Test beyond the default view

Check contrast, color dependence, zoom, and reflow

WCAG 2.2's minimum contrast ratio is 4.5:1 for most text and 3:1 for large-scale text. User-interface components and visual information needed to identify their states generally need at least 3:1 against adjacent colors. The exact calculation should be checked with a contrast tool; visual confidence is not a measurement.

Then zoom the browser to 200 percent and inspect the page. The customer should still be able to read the content, reach the navigation, operate the form, and understand any messages without important information being clipped or hidden.

• Do not use color as the only signal.Add text, an icon with an accessible name, or another cue for errors, selected states, availability, and status.
• Do not place essential instructions inside an image.Real text can resize, reflow, be selected, and be interpreted by assistive technology.
• Do not lock the page at one text size.Enlarged text should not cover buttons, vanish behind fixed headers, or force a customer to abandon the task.

07 · Describe purpose, not pixels

Alternative text depends on why the image is there

W3C's alternative-text decision tree starts with purpose and context. An informative image needs a brief description that communicates its meaning. A functional image used as a button or link needs text that communicates the action or destination. A purely decorative image should generally use an emptyalt="" value so it does not add noise.

Complex charts or diagrams need their important information in text on the page, not squeezed into a long attribute. If nearby text already communicates the same information, the image may not need to repeat it.

This also supports search clarity when done honestly. Google Search Central says alt text helps people who cannot see images and helps Google understand an image's subject. Google also warns against stuffing keywords into alt text because it creates a poor experience and may be treated as spam. Describe the image's job on that page; do not turn it into a keyword list.

08 · Make actions easier to hit

Check mobile targets, spacing, orientation, and interruptions

WCAG 2.2 adds a Level AA minimum target-size criterion of 24 by 24 CSS pixels, with defined exceptions including sufficient spacing and inline links. Treat that as a minimum test, not a design aspiration. Important buttons and controls often benefit from more room, especially when they sit close together.

Test the website in portrait and landscape where supported. Open the menu, dismiss any banner, start the form, and use the booking or call action with one hand. Pay attention to sticky elements that cover content, tiny close buttons, tightly packed links, controls hidden behind the on-screen keyboard, and taps that trigger the neighboring action.

09 · Combine evidence

Automated tools are the beginning of testing, not the end

An automated accessibility scan is valuable for repeatable checks. Run it across representative templates: homepage, service page, article, contact page, and any booking or account experience the business controls. Fix clear issues, then repeat the scan so regressions are easier to catch.

Follow the scan with keyboard testing, zoom, mobile testing, form success and error states, and a content review. W3C notes that tools can produce false or misleading results and cannot check every accessibility aspect. Where the stakes or scope are larger, bring in knowledgeable human evaluation and, when possible, feedback from people with disabilities.

10 · Start with 30 minutes

The small-business website accessibility checklist

• Choose one customer path from arrival to completed action.
• Use only the keyboard and confirm visible, logical focus.
• Read the page title and heading outline without relying on design size.
• Submit the main form with valid and invalid information.
• Measure text, component, and state contrast where required.
• Zoom to 200 percent and confirm the path still works.
• Review each meaningful image in its page context.
• Test important controls on a phone in more than one orientation.
• Run an automated scan, then manually review what it cannot judge.
• Record barriers by customer impact, page, and recommended fix.