Website Accessibility Checklist for Small Business Sites

On a small marketing site, the accessibility problems worth fixing first are also the quickest: low text contrast, missing or jumbled headings, images without alt text, vague link text, invisible keyboard focus, motion you cannot stop, and forms without labels. Work through the checklist below, then test with your keyboard, your browser's zoom and a free automated checker. No tool catches everything, but that combination finds the common problems in an afternoon.

Who this is for, and the standard behind it

Accessibility covers people who use a screen reader, zoom to 200% or more, cannot tell certain colors apart, move around with a keyboard instead of a mouse, or are sensitive to motion. It also covers anyone reading your site on a phone in bright sunlight. Several fixes (headings, alt text, descriptive links) overlap with good SEO.

The reference most accessibility policies point to is the Web Content Accessibility Guidelines. The current version is WCAG 2.2, explained in the W3C's WCAG 2 overview, and Level AA is the usual target. This checklist follows it in plain terms without covering every success criterion.

In some countries the law requires certain businesses to have accessible websites, and the rules vary by country and type of business. This is general information, not legal advice.

If your site comes from FNJ's AI website builder, some items are handled by how the pages are built and others are still yours to check. The last section says which.

1. Color and contrast

• Normal body text has a contrast ratio of at least 4.5:1 against its background.
• Large text (roughly 24px regular, or about 19px bold and up) has at least 3:1.
• Input borders, meaningful icons and focus indicators, and any button edge people need to see to find the button, have at least 3:1 against what surrounds them.
• Light grey placeholder text and "subtle" captions still meet the ratios. They often do not.
• Text over photos sits on a dark overlay or a solid panel, checked against the busiest part of the image.
• Color is never the only signal. Links inside paragraphs are underlined, and errors say what is wrong in words, not just in red.
• If the site has a dark mode, check it separately. Colors that pass in light mode can fail in dark.

Chrome's DevTools color picker shows the contrast ratio of any text you inspect, which makes spot checks quick.

2. Page structure and headings

• Every page has a unique, descriptive <title>.
• The <html> element has the right lang attribute, so screen readers pronounce the text correctly.
• There is one H1 per page, then H2s for sections and H3s inside them, without skipping levels to get a smaller font.
• The page uses landmark elements: header, nav, main and footer.
• A "Skip to content" link appears when you first press Tab, so keyboard users can jump past the navigation.

Screen reader users often move through a page by its headings, so your headings should read like its table of contents.

3. Images and alt text

• Informative images describe what matters. For a bakery's hero, "bakery" or "image1" says nothing; "Seeded rye loaves cooling on a wire rack" does.
• Linked images describe the destination. A logo that links home gets the business name as its alt text.
• Decorative images (background textures, flourishes) get an empty alt="" so screen readers skip them.
• Images containing text, like a poster or an infographic, include that text in the alt or nearby on the page.
• Alt text skips "image of". Screen readers already announce images.
• Portfolio and project images say what is distinctive: "Kitchen renovation with oak cabinets and a green tiled splashback," not "Project 3."

4. Links and buttons

• Link text makes sense on its own. "See our wedding packages" works; five links that say "Read more" do not, because screen reader users often pull up a list of all links on a page.
• Links go somewhere; buttons do something.
• Icon-only buttons, such as a hamburger menu or a close icon, have an accessible name like aria-label="Open menu".
• Tap targets are at least 24 by 24 CSS pixels, the WCAG 2.2 AA minimum. On phones, aim closer to 44 by 44.

5. Keyboard and focus

You can test all of this yourself in five minutes.

• You can reach every link, button and control with the Tab key, in an order that matches the visual layout.
• The focused element always has a visible outline. If you see outline: none in the CSS, make sure a clear :focus-visible style replaces it.
• The mobile menu opens with Enter or Space, its button announces whether it is open (aria-expanded), the next Tab reaches its links, and Escape closes it.
• Pop-ups and dialogs move focus inside when they open, keep it there while open, and return it to the trigger when they close.
• Sticky headers and cookie banners do not cover the element that has focus. WCAG 2.2 added this check.
• Nothing traps the keyboard. Check embedded maps and video players; you should always be able to Tab out.

6. Motion, animation and media

• Animations respect the visitor's reduced-motion setting, through a @media (prefers-reduced-motion: reduce) rule that switches them off or shortens them.
• Content is visible by default. If a section only appears after a scroll animation runs, it can stay invisible when JavaScript fails, the tab is in the background or motion is reduced.
• Anything that moves on its own for more than five seconds, like a carousel or a ticker, has a pause control.
• Nothing flashes more than three times a second.
• Background videos are muted and can be paused.
• Videos with speech have captions, and audio-only content has a transcript.

7. Text, zoom and reflow

• At 200% browser zoom, no text is cut off or overlapping.
• At 400% zoom (about 320 CSS pixels wide), content reflows into one column without sideways scrolling.
• The viewport tag does not disable pinch zoom (user-scalable=no or maximum-scale=1).
• Body text is at least 16px with comfortable line height, and long paragraphs are not fully justified.

A layout built with real flex and grid, rather than fixed positions, passes the reflow checks almost by default. Our post on responsive breakpoints at 1440, 810 and 390 covers how to test the widths in between.

8. Forms and widgets embedded from third parties

Small sites often embed a contact form, booking calendar, map or chat widget. You did not build them, but visitors experience them as your site.

• Every field has a visible label, not just placeholder text that disappears when typing starts.
• Required fields are marked in text, and error messages appear next to the field and explain the fix.
• You can complete the whole form with the keyboard, including any date picker.
• The embed's iframe has a title attribute that describes it, such as title="Booking calendar".
• There is an alternative if the embed fails: a link to the tool's own page, an email address or a phone number.
• Before choosing a form or booking tool, check for an accessibility statement and test its embed yourself.

For the options and trade-offs, see how to add a contact form to a static website.

How to test with free tools

Automated checkers are good at some things and blind to others:

Check	An automated tool can	You still need to
Text contrast	Flag plain text on solid backgrounds	Check text over images, hover and focus states
Alt text	Flag images with no alt attribute	Judge whether the alt text is accurate and useful
Headings	Flag skipped levels or missing H1s	Judge whether headings describe their sections
Links	Flag empty links	Judge whether link text makes sense on its own
Keyboard	Flag some missing names and roles	Check order, visible focus, menus and dialogs
Motion	Very little	Check carousels, autoplay and reduced motion

A routine for a five-page site:

1. Run the W3C's Easy Checks, a structured first review of titles, alt text, headings, contrast, zoom, keyboard and forms.
2. Run an automated scan on every page with the Lighthouse accessibility audit in Chrome DevTools, the WAVE extension or the axe DevTools extension. Fix the errors and read the warnings.
3. Do a keyboard-only pass. Put the mouse aside and use Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
4. Zoom to 200% and then 400% on a desktop browser.
5. Listen to your home page with a screen reader: VoiceOver on a Mac or iPhone, NVDA on Windows (a free download) or TalkBack on Android. Jump through the headings, then the links.
6. Turn on reduced motion in your operating system's settings and reload the site.
7. Read the site on your phone outdoors. Unscientific, but it exposes weak contrast fast.

Then publish a short accessibility statement: the standard you aim for, any known issues and how visitors can tell you about a problem.

How FNJ fits

FNJ's AI builder gives every page a real heading structure and builds layouts with real flex and grid at desktop, tablet and phone widths, which helps with the structure and reflow checks. Your colors, the alt text on images you upload, link wording and any form or booking tool you link or embed still need the checks above; FNJ does not build forms, so section 8 always applies. The export (static HTML, or a Next.js project with plain CSS) is ordinary code that you or a developer can fix directly. See how FNJ's AI website builder structures pages for every screen size.

Frequently asked questions

What accessibility standard should a small business website meet?

WCAG 2.2 Level AA is the common target and the one most accessibility policies refer to. Legal requirements vary by country and type of business, so this is general information rather than legal advice.

Are automated accessibility checkers enough?

No. They reliably catch issues like missing alt attributes, low contrast on plain backgrounds and missing form labels, but they cannot judge whether alt text is accurate, whether focus order makes sense or whether motion can be paused. Pair a scan with a keyboard test and a quick screen reader check.

Can an accessibility widget or overlay make my site compliant?

A widget added on top of the page cannot fix missing labels, poor heading structure or an inaccessible embedded form in the underlying code. Fixing the site itself is the reliable approach.