WCAG Accessibility: The Non-Negotiable Basics for Small Business Websites

WCAG stands for Web Content Accessibility Guidelines. It's published by the W3C (the international body that sets web standards) and exists in three conformance levels: A, AA, and AAA. For most small businesses, Level AA is the practical target — it's what courts and regulators reference when evaluating ADA compliance for websites, and it's achievable without a team of engineers.

The ADA (Americans with Disabilities Act) doesn't mention websites explicitly, but federal courts have consistently ruled that business websites are "places of public accommodation" under Title III. That means ignoring accessibility isn't just a usability problem — it can expose you to demand letters and lawsuits, which have increased significantly in recent years, particularly targeting e-commerce and service businesses.

The good news: WCAG AA compliance isn't about perfection. It's about hitting a defined set of criteria across four principles — Perceivable, Operable, Understandable, and Robust — which we'll walk through in practical terms below.

WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 between normal text and its background. For large text (18pt or 14pt bold and above), the requirement drops to 3:1. This matters because roughly 300 million people worldwide have some form of color vision deficiency, and low-contrast text is effectively unreadable for many of them.

Here's what that looks like in practice: light gray text (#999999) on a white (#FFFFFF) background has a contrast ratio of about 2.85:1 — a very common design choice that fails WCAG AA. Dark charcoal (#333333) on white gives you about 12.6:1, which passes comfortably. You can check any color combination for free using tools like the WebAIM Contrast Checker (contrast checker by webaim.org) or the browser extension Colour Contrast Analyser.

Don't just check your body text. Check your navigation links, button labels, placeholder text in forms, and any text overlaid on images or colored backgrounds. Form placeholder text is a frequent offender — browsers often render it at reduced opacity, which tanks the contrast ratio even if the color itself looks fine.

Alt text (the `alt` attribute on an `<img>` tag) is what screen readers announce to blind or low-vision users instead of displaying the image. Writing it well is one of the highest-impact, lowest-effort accessibility improvements you can make.

The core rule: describe what the image communicates, not what it depicts. If you have a photo of your storefront on your contact page, the alt text isn't "photo of storefront" — it's something like "Exterior of Maple Street Bakery, located at the corner of Maple and 3rd." If the image is a chart showing your service tiers, the alt text should summarize the key data point the chart conveys.

Decorative images — dividers, background textures, abstract flourishes — should have an empty alt attribute (`alt=""`). This tells screen readers to skip the image entirely, which reduces noise for users who are navigating by keyboard or audio. Leaving the alt attribute out entirely is different and worse: the screen reader may announce the filename instead, which is useless and disorienting.

For product images in an e-commerce context, include color, material, and any key detail visible in the image that isn't covered in the product description — for example, "Dark navy canvas tote bag with reinforced leather handles and interior zip pocket."

Many users — not just those using screen readers — navigate websites entirely by keyboard. This includes people with motor disabilities, power users, and anyone whose mouse has died mid-workday. WCAG AA requires that every interactive element on your page — links, buttons, form fields, dropdowns, modals — be reachable and operable using only the Tab, Enter, Space, and arrow keys.

The most common failure here is removing the browser's default focus outline (the blue or dotted border that appears around a focused element) in CSS without replacing it with something visible. Designers often remove it because it looks "messy," but for keyboard users it's the equivalent of a cursor — without it, they have no idea where they are on the page. WCAG 2.2 (the current version) strengthens the focus visibility requirements even further.

To test keyboard accessibility yourself: put your mouse aside and try to complete a task on your own website using only the keyboard. Can you navigate your main menu? Fill out your contact form? Close a cookie banner? If you get stuck or lose track of where you are, you've found a failure. Pay special attention to dropdown menus, date pickers, and any custom JavaScript components — these are where keyboard traps most commonly appear.

Proper page structure is what allows screen reader users to skim and navigate efficiently — the same way sighted users use visual hierarchy. Every page should have a single H1 that describes the page's main topic, followed by H2s for major sections and H3s for subsections. Don't choose heading levels based on how they look; use CSS to style them, and use heading levels to communicate structure.

Forms deserve specific attention because they're where small business websites most often fail accessibility. Every input field must have a visible, programmatically associated label — not just placeholder text. Placeholder text disappears when a user starts typing, provides no persistent label for screen readers, and typically fails contrast requirements. The label element in HTML connects a label to an input via matching `for` and `id` attributes, and this association is what screen readers rely on to announce what each field is for.

Error messages also need to be specific and programmatically connected to the field that has the error. "Please fill in all required fields" is vague and unhelpful. "Email address: please enter a valid email (example: name@domain.com)" tells the user exactly what's wrong and how to fix it. This is better UX for everyone, not just users with disabilities.

If you're starting a new site and want to skip the accessibility headaches of building from scratch, Template Vault generates websites with semantic HTML structure and accessible form markup baked in by default — a much faster starting point than fixing these issues after the fact.

Beyond alt text for images, any video content on your site raises additional WCAG requirements. Prerecorded video needs captions (not auto-generated YouTube captions without review — they're often inaccurate) and ideally an audio description track if the video contains visual information not conveyed in the audio. Live video requires live captions.

For audio-only content like podcasts, you need a transcript. Transcripts also help with SEO — search engines can't index audio — so this is one of those accessibility features that pays dividends beyond compliance.

If you embed maps (like a Google Maps embed on a contact page), add a text alternative nearby: a plain-text address and written directions. The map embed itself is largely inaccessible to screen reader users, so the text alternative is what does the real work.

Background videos — a popular hero section trend — should be pausable, and they should not autoplay audio. WCAG specifically prohibits audio that plays automatically for more than three seconds without a mechanism to stop it. If you want the visual effect of a looping video background, mute it by default and make sure users can pause it, both for accessibility and for users on metered connections.