Small-Business Website Accessibility Checklist: What to Fix Before Launch

A small-business website is accessible when people with different abilities can understand the offer, navigate the content, operate the controls, complete the important action, and recover from mistakes. That definition is more useful than a badge, a score, or a promise that an overlay will solve everything.

The checklist below is designed for a local service business, professional practice, studio, retailer, restaurant, or compact online offer. It is not a legal opinion or a claim of conformance. The W3C Web Content Accessibility Guidelines 2.2 recommendation is the technical reference; the Department of Justice guidance on web accessibility and the ADA explains why inaccessible online services can deny people equal access and describes practical barriers. Your business, location, industry, and customer path may require additional review.

Start with the pages that carry the business

Do not begin by checking a random archive page while the quote form is impossible to complete. List the paths that create business value and test those first:

• the homepage or campaign landing page that explains the offer
• the primary service or product page where buyers compare options
• the contact, quote, booking, or checkout flow
• the confirmation state that tells a person what happens next
• the location, hours, policy, or pricing page needed before a decision

Write down the user goal for each page. “Submit the form” is not enough. A prospective client may need to choose a service, enter a service area, describe the problem, select a date, review consent language, and know when a response will arrive. Accessibility testing becomes concrete when the team can state what success means for an actual customer.

Use the page-planning guide to keep the first release focused on distinct customer decisions. Fewer purposeful pages are easier to test and maintain than a large site whose important paths are buried.

Check headings, landmarks, and reading order

Visual hierarchy should also exist in the document structure. A person using a screen reader, keyboard shortcuts, browser outline tools, or a small viewport needs a predictable way to understand the page.

• Use one clear page heading that describes the page purpose.
• Use headings in a logical order, without choosing a heading level only because it looks smaller.
• Use landmarks such as header, navigation, main, complementary content, and footer when they clarify the page.
• Give repeated navigation and controls understandable names.
• Keep the DOM reading order aligned with the visual and task order.
• Make link text meaningful without requiring the surrounding paragraph to explain every “learn more.”

The W3C WCAG 2.2 Quick Reference is useful for mapping these checks to success criteria and techniques. Treat the reference as a way to organize review, not as permission to add a long list of technical labels to a proposal without testing the customer experience.

Inspect the page with styles disabled or a text-only reading view. If the offer, price logic, service area, proof, and next action become unintelligible, the design may be relying too heavily on visual placement or decoration.

Operate every important action without a mouse

Put the mouse aside and use the keyboard alone. Press Tab through the page, Shift+Tab backward, Enter or Space to activate controls, and Escape where a dialog should close. The focus indicator must remain visible and should not disappear beneath a sticky header, cookie banner, or modal.

• Every link, button, menu, dialog, carousel, date picker, and form field is reachable.
• Focus moves in a sensible order and does not jump unexpectedly.
• No component traps focus or makes the page impossible to leave.
• Expandable navigation and dialogs announce their state and return focus appropriately.
• Sticky elements do not cover the focused control or the error a person needs to fix.
• Visible labels and accessible names describe the same action.

WCAG 2.2 added criteria for focus not being obscured and for minimum target size, but do not turn those into isolated box-ticking exercises. A telephone link that is technically focusable but covered by a fixed banner still blocks the buyer path. A tiny icon that works only after several precise taps creates friction even when an automated scan is quiet.

Test the actual navigation pattern on a phone and a desktop keyboard. A custom menu can look polished and still fail when its trigger is not a real button, its expanded state is not communicated, or its focus returns to the wrong place.

Make forms understandable, forgiving, and complete

Forms are where accessibility and conversion become inseparable. A person should know what information is required, why it is requested, what format is expected, and whether the submission succeeded.

• Give every field a persistent, programmatic label, not only placeholder text.
• Group related choices with a useful legend and identify required fields in text.
• Describe formats before submission, such as a phone number or preferred appointment date.
• Keep entered values when validation fails so the person does not have to start again.
• Place an error summary where it can be found and connect each error to its field.
• Explain how to correct the value in plain language, not only with a color change.
• Announce important status messages without forcing a screen-reader user to search the page.
• Confirm what was submitted, who receives it, expected response time, and an alternate contact method.

The ADA guidance lists labels, clear instructions, keyboard access, and useful error indicators as examples of accessible online forms. It also warns that automated checkers and overlays can help but cannot establish that a page is accessible. Read the guidance as an operational reminder: the form has to work for a person, not merely pass a report.

Run a real submission in a production-like environment. Check validation, spam protection, email routing, CRM or booking handoff, confirmation copy, and analytics. Do not ask a customer for information in the form that the business cannot protect, use, or explain.

Give every meaningful visual and media asset a usable alternative

Alternative text should communicate the purpose of an image in context. A photo of a completed bathroom remodel might need a concise description on a project page, while a decorative background should be ignored by assistive technology. A logo link needs the business name and destination, not a filename.

• Write short, specific alt text for informative images.
• Use an empty alternative for genuinely decorative images rather than repeating nearby copy.
• Provide captions for video and transcripts when the spoken or visual information matters.
• Do not put essential instructions, pricing, or service boundaries only inside an image.
• Publish accessible HTML for important documents when possible, not an image-only PDF.
• Make charts, before-and-after comparisons, and maps understandable without color alone.

The W3C Easy Checks offers a practical first pass for images, headings, contrast, keyboard use, and forms. Its purpose is to find obvious problems, not to certify a complete result. Ask whether the alternative actually helps the person make the same decision as someone who sees the image.

Review contrast, text size, zoom, and motion

Visual polish should survive the settings real visitors use. Check body text, links, buttons, placeholder text, disabled-looking controls, focus indicators, charts, and text over photographs. Do not communicate required, successful, or urgent information through color alone.

• Text remains readable when a person increases browser zoom.
• Content reflows without horizontal scrolling at common narrow widths and zoom levels.
• Focus, error, and selected states have enough contrast to be recognized.
• Buttons and links retain their meaning when color is removed.
• Animations can be paused or avoided when they create distraction or discomfort.
• Text does not disappear behind overlays, sticky bars, or cropped cards.

Use a contrast tool to find candidates, then inspect the actual text, font weight, background image, hover state, and focus state. A mathematically acceptable color pair can still be hard to read when the type is small, thin, crowded, or moving.

Google's mobile-first indexing guidance says Google uses the mobile version of a site's content for indexing and ranking and recommends responsive design. That is a search consideration, but it is also a buyer-path requirement: the mobile version must include the same offer, proof, metadata, headings, and action rather than hiding the useful content behind interaction or a smaller alternative page.

Treat performance and third-party widgets as access concerns

A slow or unstable page can be inaccessible in practice, especially for visitors on older phones, high-latency connections, assistive technology, or limited data plans. Check the page with real images, fonts, maps, chat, video, analytics, booking widgets, and consent tools enabled.

Google's Core Web Vitals documentation describes loading performance through Largest Contentful Paint, responsiveness through Interaction to Next Paint, and visual stability through Cumulative Layout Shift. Use those metrics as signals, then connect them to human checks. A good score does not prove that a person can understand the offer or submit a quote, and a poor score does not tell you which customer action is blocked without investigation.

• Reserve image dimensions so content does not jump as assets load.
• Keep the first customer action usable while nonessential scripts load.
• Give embedded booking, payment, map, and chat controls enough labels and keyboard support.
• Provide a visible alternate contact path when a third-party widget fails.
• Test consent controls without making the site unusable to keyboard or screen-reader users.

If an external widget cannot meet the needed experience, treat that as a procurement and scope decision. Do not hide the problem behind a decorative link or declare the page complete because the rest of the site works.

Combine automated scans with manual checks

Run an automated accessibility scan against representative pages and fix obvious issues such as missing labels, duplicate IDs, invalid names, and contrast candidates. Then perform a manual review because tools cannot determine whether a heading structure communicates the offer, whether alt text is useful, or whether an error message tells a person how to recover.

A focused manual pass can use this order:

1. Read the page with a keyboard only and record every focus problem.
2. Increase zoom and text size, then check reflow, clipping, and fixed overlays.
3. Use a mobile device with touch and a slow connection simulation.
4. Inspect headings, landmarks, labels, link names, alt text, captions, and document order.
5. Complete the form or booking path with valid and invalid values.
6. Use a screen reader or arrange testing with people who use assistive technology.
7. Repeat after the highest-risk defects are corrected and save the acceptance notes.

Keep the record specific: URL, device or browser, action attempted, observed barrier, severity, owner, correction, and retest result. “Accessibility improved” is not a useful handoff note. “On the quote form at 200% zoom, the required-service error appears below the sticky footer and focus does not move to it” is actionable.

Prioritize barriers by customer and business impact

Fix blockers on the primary revenue path first. A missing alternative on a decorative footer icon matters less than a quote form that cannot be submitted by keyboard, a phone number that is not identified, or a booking widget that has no accessible error state.

This ordering protects the business from spending a week perfecting a blog archive while the page that creates calls remains difficult to use. It also makes accessibility a practical part of the traffic-to-lead diagnosis.

Decide whether remediation or a rebuild is safer

Most sites can improve without a complete rebuild. Repair the current site when its markup, content model, forms, and platform can support semantic structure, keyboard behavior, readable responsive layouts, and maintainable fixes. Start with high-impact templates and test each shared component wherever it appears.

A focused rebuild may be reasonable when the theme prevents accessible navigation, the page builder generates unusable markup, the current form or booking vendor cannot expose required states, or the business cannot control essential accounts and updates. A rebuild creates migration risk, so inventory URLs, redirects, analytics, forms, content, and ownership before choosing it. The website redesign and SEO migration checklist covers the search-protection work that belongs alongside the accessibility plan.

Do not accept a proposal that says “ADA compliant” without scope, testing methods, standard or criteria, third-party boundaries, ongoing responsibilities, and an escalation path. The web designer scorecard can help compare acceptance criteria, account ownership, accessibility review, security, revisions, and total cost. A provider should be able to explain what was tested and what remains outside the project.

Make accessibility part of the operating handoff

Accessibility is not finished when the launch screenshot looks good. New photos, service pages, PDFs, discounts, embedded widgets, and form changes can introduce barriers. Assign someone to review content and shared components as the site evolves, and include a repeatable check in the maintenance routine.

• Keep domain, hosting, analytics, Search Console, form, and recovery accounts under business control.
• Document the supported browser and device scope, test pages, known limitations, and retest date.
• Give content owners a short guide for headings, link text, alt text, captions, tables, and documents.
• Provide a visible way for visitors to report an accessibility problem and route it to a real owner.
• Review templates and third-party widgets after upgrades, not only after a redesign.

Use the small-business website maintenance checklist to turn this into an operating habit. If the project still needs a build, compare Zendory's website packages, inspect the website examples, and normalize the complete scope against the website cost guide. The right deliverable includes the pages, content, forms, testing, launch verification, ownership, and post-launch responsibility the business actually needs.

Primary standards and guidance used for this checklist

These first-party references are useful starting points. They do not replace testing with real users or advice about a specific legal situation.

• W3C Web Content Accessibility Guidelines 2.2, the current technical recommendation and success criteria.
• W3C WCAG 2.2 Quick Reference, a practical way to organize criteria and techniques.
• ADA.gov Guidance on Web Accessibility and the ADA, including examples of barriers in content, forms, keyboard access, and testing.
• W3C Easy Checks, an introductory manual review of common accessibility signals.
• Google Search mobile-first indexing best practices, for keeping mobile content and metadata equivalent and usable.
• Google Search Core Web Vitals documentation, for loading, responsiveness, and visual stability signals.

A website does not become trustworthy because a scanner reports zero issues. It becomes more useful when a real person can find the right information, operate the interface, complete the action, and recover when something goes wrong. Make those checks part of the brief, the build, the launch, and the maintenance plan.